4 ms·
For me it's because there are very few databases (you can count them on one hand) that check the following boxes: * Document or SQL Storage * Integrated Full T
by ssmoot 11y ago
For me it's because there are very few databases (you can count them on one hand) that check the following boxes:
* Document or SQL Storage
* Integrated Full Text Search
* Can transparently survive a node going down (load balancer or client driver support)
* Highly consistent by default, or allow operation level quorum settings
* DR options with minimal lost writes
* Transaction support
* Hosted
* Affordable for small businesses with low average load, but including the occassional peaky or seasonal issues (large bulk imports, auto/consumer/product/etc-show traffic spikes for a few days, etc)
Cloudant meets everything but Transactions. But that's a big one.
Most databases you might think of don't satisfy the Hosted option. And considering how easy it is to loose other items on the list through misconfiguration or maintenance issues, that's a lot more of a core feature than might be obvious for a small shop. It's great if node failure is transparent in theory, but if it doesn't work in practice it may as well not exist.
Most of the rest don't integrate full-text-search. That's huge. It means a ton of concerns move from the database vendor, to you, the application developer. Any database that doesn't (at least plan to) integrate full-text-search is one with a much higher development and operations cost.
And the number of databases that promise to (eventually) deliver distributed SQL? There was 1 a few years ago (AFAIK) that met most of those: FoundationDB. Never to be heard from again. :-)
I don't need a GraphDB for my CMS-like sites. That's just not a very good fit. And working without JOINs (though it sounds like they're on the roadmap here) is not as onerous as you'd imagine for many sites, and it often brings along the side-effect of forcing you to write a much more efficient/fast product against denormalized data.
So any database that promises to check most of those boxes is worth keeping an eye on (IMO). Though the things that kill most solutions candidacy for me are:
- lack of integrated Search
- lack of Hosted/Managed option
Everything else is pretty flexible.
- lobster_johnson 11y agoWe're building something that satisfies all of those criteria. We call it a data layer, not a database, because it's a higher-level document data model layered on top of Postgres (with pluggable data stores that can be added at runtime; we hope to support other backends such as Redis and Cassandra and maybe CockroachDB if it's a good fit) and Elasticsearch (also intended to be pluggable), similar to how TitanDB is implemented. It supports transactions — atomic multi-document updates within a single data store that supports this — fine-grained CRDT-style document patching, update streaming, versioned schemas and a fine-grained permissions system. The query language isn't SQL, but our own relationship-oriented, vaguely GraphQL-like query language that allows querying on anything that Elasticsearch can express, as well as complex joins and aggregations. Since Elasticsearch is eventually consistent and all queries go through it, we aim to provide some consistency-tolerance semantics when a client does need strict consistency in combination with queries. We're not quite ready to publish the code, but drop me line (email in profile) if you want to be notified when it becomes available.