6 ms·

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I

• cwnyth 3mo ago
  What's wrong with MariaDB?
  • chuckadams 3mo ago
    Last I looked, MariaDB still implemented JSON columns as LONGTEXT under the covers, making it a non-starter for any serious use of said type.
• pbronez 3mo ago
  I am currently fighting my way off SQL Server towards PostgreSQL. Windows Server is a real pain to operate and the SQL Server ecosystem expects you to run a lot of add-ons on the server alongside your database. Those don’t translate to managed database services, so you lose a lot of functionality if you jump to RDS or similar. The first party tools are also aging poorly. SSIS and SSRS are not fun. SSMS is ok for what it is but can’t compete with the ecosystem around PostgreSQL. Maybe I’m missing something but I can’t wait to ditch it.
  • hotsauceror 3mo ago
    What are some of the add-ons that you run on the server? We run ours in a pretty bare-bones manner so I'm interested to hear what you're doing.
    • FuriouslyAdrift 3mo ago
      The linux version runs very cleanly, too. https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-release-notes-2025?view=sql-server-ver17 https://learn.microsoft.com/en-us/sql/linux/sql-server-linux...
  • aljgz 3mo ago
    Agree about Windows Server. You can run SqlServer on Linux though. I'm not aware of your specific addons, but the Sql Server itself works perfectly well on Linux.
  • FuriouslyAdrift 3mo ago
    SSMS has been rebuilt as a framework within Visual Studio, now. It includes Copilot AI and a bunch of other niceties.
• d125q 3mo ago
  Care to share some examples where SQL Server's indexed views would shine? In my eyes they're similar to triggers, which incur a high performance overhead in OLTP systems and are shunned by developers. In OLAP systems custom ETL code will likely outperform them.
  • mickeyp 3mo ago
    These things exist to eliminate the risk of ever serving stale information from a materialised view. I.e., their benefit is political/reputational as much as they are technical in the sense that they save you effort like remembering to invalidate a MV after an ingest operation. Stale MV is a thing you only ever burn your fingers on once. Like how "It's not DNS" is a common meme in networking.
  • aljgz 3mo ago
    Indexed views are much faster than trying to achieve the same result with triggers. Triggers have serious concurrency limitations, and you do recalculations even when the fields you depend on are not touched. Indexed views are not much worse than indexes. Of course, when they refer to other tables there are underlying data lookups, but in our experience when we moved from triggers to indexed views, large scale data ingestion went way faster. Where we used it: While revamping a large scale sales program, we stored the warehouse in/out in one table, and several things like current stock were calculated using indexed views. Bonus: Using Snapshot concurrency control, you can do many things concurrently, and only when they both updates to a certain product in the same store you'll get the second transaction failing (which could be retried on the backend). The fact that they are completely in-sync with your data is amazing.
    • switchbak 3mo ago
      PG has had incremental view maintenance on the horizon for many years. I expect it to remain on the horizon for a long time. What you're describing is amazing, and I wish I had it available to us. We've hand rolled far too many triggers to achieve the same thing, with all the expected problems you'd assume. I'm sure it could be abused/misused, but a batteries-included approach like that would be huge.
• ksec 3mo ago
  >I do myself a favor and always avoid Oracle and MySql/MariaDB. So what's wrong with MySQL or MariaDB?
  • phamilton 3mo ago
    Just a set of things too minor to move off of it but annoying enough to not want to start with it. My list: No `explain (analyze,buffers)`. Instant DDL has some warts (e.g. fk, metadata locks). Query planning bugs (actually... query planning in general is disappointing). Exiting the repl doesn't stop queries. Implicit type casting. Replication lag from large DDL (e.g. creating an index). Lack of two phase DDL (creating constraints NOT VALID and then VALIDATE later). Lack of extensions (e.g. pg_vector). No safe access to inspect buffer cache. AWS Aurora seems to only add shiny new things to Postgres. And more. Again, none of this is quite enough to migrate off of it for an established system, but certainly enough to avoid it on a new project.
  • rmunn 3mo ago
    Don't know of anything wrong with MariaDB, but there used to be plenty wrong with MySQL. To give the most egregious example (THANKFULLY fixed in MariaDB, but was present in MySQL for the longest time), inserting the value 128 into a TINYINT column (signed 8-bit int) would clamp the value rather than returning an error. Which might be what you want... except if that was a primary key column. Marvel at the following, which used to be how MySQL behaved: Note: the below taken nearly verbatim from https://sql-info.de/mysql/referential-integrity.html#3_5 https://sql-info.de/mysql/referential-integrity.html#3_5 CREATE DATABASE foo; USE foo; CREATE TABLE one ( id TINYINT NOT NULL PRIMARY KEY ) TYPE=InnoDB ; CREATE TABLE two ( id TINYINT NOT NULL PRIMARY KEY, INDEX (id), CONSTRAINT id_fkey FOREIGN KEY (id) REFERENCES one(id) ) TYPE=InnoDB ; Now that we've created both tables, let's insert a record into table one: INSERT INTO one VALUES (127); And now let's insert a record with a different primary key into table two: INSERT INTO two VALUES (128); MariaDB will give you an error at this point (ERROR 1264 (22003): Out of range value for column 'id' at row 1), but MySQL (at least back when I tried this about ten years ago, which was the last time I was forced to work with MySQL — and I am so glad I never have to go back!) would return no error message and just say "Query OK, 1 row affected (0.009 sec)". Now let's select the value we inserted into table "two": SELECT * FROM two; And what do we see? The value 127, even though we inserted 128. Which has created a foreign-key relationship to table "one" that we never intended to put in there. There are other reasons why MySQL was inadequate, but I no longer remember them. Probably MariaDB has fixed them by now. But I no longer have to use MySQL/MariaDB for anything, and I never want to go back. I have a VERY strong averse reaction, caused by past pain, when I think of using MariaDB. (I actually spun up a virtual machine to test what I wrote here, because there's no way I was going to install MariaDB on my primary work machine).
• bob1029 3mo ago
  SQLite and MSSQL are my two solutions for relational storage problems. If I am going to use a "free" provider, SQLite is impossible to beat. They cover a majority of use cases today. SQLite starts to fall apart with backup, replication and tooling. If I am on the hook for things like system availability and disaster recovery, I don't have a problem spending money to cover my ass. If I am going to pay any amount of money at all, I am going all the way. The developer experience around MSSQL is untouchable. SSMS and VS with sql projects runs circles around contemporary entity framework crap. Sprinkle in 3rd party tools from vendors like RedGate and you can replace multi-million dollar consulting packages. I wouldn't ever advocate for standing up a new Oracle or DB2 machine, but if one was already in place I'd probably die on the hill of not trying to refactor it away. These databases typically come with multi-volume ghost stories attached. Reinventing all those weird effects on a new engine will typically kill the business if there are no other options available.
  • colechristensen 3mo ago
    Can you expand on what is better with MSSQL?
    • bob1029 3mo ago
      One of the biggest advantages is that a lot of people in the business are already comfortable with the ecosystem. I know that from the perspective of HN that SSMS, pgAdmin, DBeaver, DB Browser for SQLite, et. al. are mostly isomorphic, but from the perspective of everyone else in the business, these are substantially different things to think about. Whether the popularity of the MS ecosystem is good or not is a separate problem. If we are solving for "make the business go well and I get paid more", the strategy is usually obvious. We can still advocate for OSS and not-so-many-eggs in the Microsoft basket while we get paid for using these technologies. Again, SQLite is the preferred engine in my tool belt. I don't want to have to manage a hosted sql machine. But, sometimes the problem absolutely insists upon it. Also, if you are using C#/.NET, integrating with MSSQL is always a little bit easier than the other providers. SQLite (and some others) have lackluster types for things like time. MSSQL has DateTime2 and DateTimeOffset that map exactly into the CLR types.
• asah 3mo ago
  two techniques I use with pg: 1. "materialize" the view as a full table, then index that. Any reasonable pipeline/ETL tool can provide incremental updates between tables. Obviously, anything materialized requires considerations around storage, replication, backup/restore, I/O, etc. 2. use a regular VIEW and index (precisely) the underlying expressions mentioned in the view, i.e. so when the view is used, then the indexes get used. Both require rewriting SQL, though I've used VIEWs to make the change transparent.
  • ballon_monkey 3mo ago
    Materialized views in pg with any incremental updates has timing inconsistencies that SQL Server doesn't have.
• joinjune 3mo ago
  Oracle = Pain, Suffering, High Costs, Litigation, and Human Misery. If it wasn't for non-technical middle management that likes the perks of buying high cost software from vendors that throw nice parties they'd be out of business.
  • cduzz 3mo ago
    Oracle makes their money by promising the C Suite "give us money and we'll solve your problems." There aren't actually many companies in a position to credibly make that promise. The oracle database is also actually pretty nice, according to the people I've talked to who use it. But mostly they play in the 'nobody ever got fired for suggesting' club. These days AWS is the most egregious landlord of that club, but whatever.
• SigmundA 3mo ago
  I also miss clustered indexes, datetimeoffest, plan caching and query hints from MSSQL.
• zbentley 3mo ago
  > lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurrent connection. Pg connections are definitely heavy, but usually on resources other than memory in my experience. If you configure reasonable dirty reclamation and recycling, the memory numbers are often overstated due to Linux tools’ deceptive fork accounting and shared buffers. Ofc, if you’re averaging lots of heavy queries per connection it’ll be truly heavy, but many times the numbers overstate the impact.
  • SigmundA 3mo ago
    Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection which has a max of 32k per instance. There are no need for connection poolers in front of MSSQL although it is normal to pool connections in the client application which may hold hundreds open typically in a web server. This also allows MSSQL to more easily share cached query plans between connections since its just sharing executable code between threads. For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way. PG has it obvious unix roots using processes instead of threads, MSSQL coming from Windows where new process are expensive and there was no real fork, but threads are cheap uses that approach instead.
    • CraigJPerry 3mo ago
      >> Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection There's no free lunch id think, the PG model is more robust. Unsafe extensions can take down the whole instance in the threaded model, processes contain the blast radius to that connection (also typically easier to debug since this type of issue is thankfully rare, it's also gnarly to get on top of). Further, on linux (not on windows) a lot of the lines between a thread and a process get blurry (copy on write, shared memory mappings etc). They're both handled very similarly in the kernel, theyre both scheduled using similar machinery. >> For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way. Is that true? I'm thinking the buffer cache and locks and WAL coordination are just as fast - it's just mmap'd SHM into each process. It's not like every access needs IPC?
• khurs 3mo ago
  Postgresql is the better product, but doesn't have the horizontal scaling of MySQL/Maria though, so if you want an easy to setup cluster MySQL for high volume online retail store or similar has a use case still.
  • brightball 3mo ago
    I think we take for granted how few databases ever outgrow vertical scaling needs. Usually there will be one or two tables that grow at a dramatically faster rate than everything else and I have always found that those belong in a separate data store.
    • roncesvalles 3mo ago
      You need replication for HA. Otherwise the only HA you have is the RAID setup on the one machine. The reason people go horizontal is rarely scale. And if you're doing that you might as well use the passive replica as a read replica.
      • brightball 3mo ago
        Read replication is easy. Horizontal scaling for DB typically means distributing the write load across instances either via sharding or master-master. I could be wrong of course, but that’s how I read it. MySQL is very good at master-master out of the box.
        • roncesvalles 3mo ago
          To be pedantic, master-master implies the same row can be committed to at the same time at different master nodes (without an immediate causal connection between the two). Very few databases allow this.
  • kev009 3mo ago
    This hasn't been true for quite a long time, because it's domain of other products for both. i.e. MySQL/Maria's MM is one of the worse options compared to anything else.. like TiDB or Aurora on AWS for MySQL compat and Yugabyte or CockroachDB for Postgres compat (or Aurora on AWS or AlloyDB on GCP).
• zepearl 3mo ago
  > Synchronously updated materialized views... Oh yes, I'd love them too (if you're referring to, in Oracle slang, "...update on commit") - and it would be cool to have as well the option for a lazy update ("on demand" by taking into consideration only the records that have been changed since the last refresh, to handle multiple updates in a single pass - not sure how Oracle can achieve that technically...). This would be in my opinion a fantastic added functionality compared to basically all other (OLTP?) opensource DBs. And: I'm really curious about the "OrioleDB" project... ( https://github.com/orioledb/orioledb/releases https://github.com/orioledb/orioledb/releases ) as a few years ago I was struggling a lot with "vacuum" of a kind-of-temporary table that had quite high amounts of continuous random inserts & deletes (problem solved by accumulating more changes in RAM before flushing them to the table therefore increasing amount of rows changed per "page", but I had to sweat a lot to find a good balance...).
  • gandreani 3mo ago
    Clickhouse offers the same through https://clickhouse.com/docs/materialized-view/incremental-materialized-view https://clickhouse.com/docs/materialized-view/incremental-ma.... I personally LOVE this feature and concur with the gp that they're really elegant solutions to difficult problems. Just to give an example, I ingest otel trace spans individually and in a materialized view calculate the total duration of the whole trace among other things.
    • ddorian43 3mo ago
      Its not transactional or atomic.
• brightball 3mo ago
  > 2. Synchronously updated materialized views (Sql Server calls them indexed views). These are incredible tools in complex data situations. I saw a project struggle with complex technical implementations that would be elegant, trivial and always correct with indexed views. I believe you can do this with the pg-trickle extension. https://github.com/trickle-labs/pg-trickle https://github.com/trickle-labs/pg-trickle
• deleted 3mo ago
  [deleted]
• timacles 3mo ago
  I think even Microsoft has abandoned SQL Server and spends more time improving their various Postgres Azure offerings. Their last major version release since 2022 added some AI features and thats it. As a DBA, who does a lot of very heavy DBA like stuff, Postgres is in another league from SQL Server. Because Postgres is linux native and open source, its flexibility, introspection and operability, just doesnt have a comparison in SQL Server. IMO, in the current tech landscape. SQL Server is essentially dead. Only companies using it are legacy windows shops which there are fewer and fewer of.