The Database Zoo: Exotic Data Storage Engines - why SQL and NoSQL aren't enough anymore
Posted by OtherwisePush6424@reddit | programming | View on Reddit | 20 comments
The post walks through the history of SQL and NoSQL, then makes the case for why general-purpose databases can't handle every modern workload and why a whole ecosystem of specialized engines emerged to fill the gaps. It's the first post in a series covering time-series, vector, and probabilistic databases in depth.
IiIIIlllllLliLl@reddit
Maybe a hot take but I don't think a Database "Zoo" is either needed or desirable. Get an OLTP database and an OLAP database (I'd suggest Postgres and ClickHouse), and 90% of your real life use cases are covered.
Konkord720@reddit
Does it use SQL? No? Then it is a nosql
dimon222@reddit
Is it good time to point out that NoSQL was created as short from "Not only SQL", not "No SQL"?
Tysonzero@reddit
This is why most refer to postgresql as a nosql db due to the nonstandard extensions.
oceantume_@reddit
Aren't most SQL databases with modern features fitting that description then?
Tysonzero@reddit
One single additional function not in the sql spec, believe it or not, right to ~~jail~~ nosql.
this_is_a_long_nickn@reddit
I’m waiting for the quasiSQL vibe coded engines
elperroborrachotoo@reddit
Thank you, Mr. Fun at Parties.
chat-lu@reddit
It makes No SQL a rather useless expression.
Do you go swim in a bathing suit, or no pants clothing?
Cultural_Break_6920@reddit
hot take: most 'best practices' are just opinions that worked for one specific team at one specific company. the actual best practice is understanding the tradeoffs and making deliberate choices for your situation.
stuff that's universally good: tests, ci/cd, monitoring, documentation. everything else depends on context.
Rough-Bank-8638@reddit
SQLite and Postgres already handle time-series and vector workloads well enough for most teams, so the "gap" is narrower than the article implies. Specialized engines make sense at massive scale, but for 95% of apps a general-purpose database with proper indexing will outperform a niche solution that adds operational complexity. We wrote about when indexes actually hurt performance here — https://ellomas.com/resources/articles/database-indexes
ImNotHere2023@reddit
Relatively poor article - while I think most understand a SQL database to refer to an ACID compliant database using a SQL query engine, you can actually put a SQL query engine in front of all sorts of things. You can also build databases that enforce only a subset of ACID guarantees, or even selective enforcement on a per-query basis (e.g. stale reads in Cockroach).
There's far more room for innovation within the realm of SQL databases than the author is giving credit, and they completely misunderstand the term No SQL, which itself refers to a wide spectrum of database types.
helpprogram2@reddit
I’m so exhausted by these marketing terms
dragenn@reddit
Vibe-basing anyone!?!?!?
TyrusX@reddit
This whole profession is pure garbage now
deleted_by_reddit@reddit
[removed]
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
beders@reddit
Make sure you take a look at Datomic as well
superrugdr@reddit
No SQL arise from necessity really.. Necessity to sell non managed VM maybe.
No SQL use the same selling tactics as cloud computing pricing.
Promise scaling, but then you need to pre shard based on xyz. Thing is if you had done that with any SQL database at the start you wouldn't have had that problem to begin with.
Also the article seems to omit the most important bit.
Database is nice. But binary file and plain old log are actually a lot older and a lot more useful and overlooked.
All in all it felt like a primer I could get from asking chatgpt.
spinur1848@reddit
Non-exhaustive. Clearly the author has some favourites (which is fine), but if you're going to call your book "The Database Zoo" there's an expectation of some rigour.