Redis and Cassandra already handle distribution out of the box.
It seems like there product is basically a web GUI for creating db tables with workflow automation so it doesn't seem like too far of a stretch to have 1 table per customer table. I guess the alternative is designing some system for shoving arbitrary schemes into another schema.
I guess https://en.m.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%... is an option
They didn’t build a DB, they taped some products together with middleware. That isn’t to say what they did is bad, just that it’s not “let’s write a DB from scratch” as the headline implies.
One thing that stopped me from trying it in the past for a project was this:
> Is rqlite a good match for a network of nodes that come and go – perhaps thousands of them?
> Unlikely.
While I wasn’t going to get to thousands, it was going to be hosted on K8s, and it seemed like I’d have to write lifecyclehooks to ensure nodes gracefully left consensus, and others felt that was an unnecessary complexity for the problem. Can you speak more to this point, since in the FAQ you also say it can run on K8s? If a node dies due to, say, hardware failure, when it rejoins is it seen as a slightly out-of-date existing node since it’s part of statefulset? If so, assuming quorum is maintained, this is probably a lot easier than I was making it out to be.
However, running it on Kubernetes should work quite well. Check out the documentation at https://rqlite.io/docs/guides/kubernetes/
>If a node dies due to, say, hardware failure, when it rejoins is it seen as a slightly out-of-date existing node since it’s part of statefulset? If so, assuming quorum is maintained, this is probably a lot easier than I was making it out to be.
Assuming I follow you, yes, this should work fine -- and exactly as you expect. I suggest you try it out, and if you don't understand what you're seeing file a ticket on GitHub, or join the rqlite Slack[1].
AirTable developed their own DB, but their case may be justified. I listened to an interview with a founder once - very thoughtful and reasonable. They fully understood what they were getting into.
But by default, NEVER:
* Write your own DB
* Write your own search engine to match ElasticSearch or other serious technologies
It will take over your life, and then ruin it.
If you ever find yourself in a position where you need a database table per instance of an abstraction, you've almost certainly failed to model the domain appropriately.
If you find yourself in a position where you think you need to write your own database engine because nothing on the market can even approach your problem, you probably need to go take a nap.
The only instancing that makes sense to me is at the database level (aka one per customer/board/etc), and if you're going to be doing a lot of database files... Did SQLite even remotely cross the mental threshold here? I can see several ways to make it solve this problem if you are going to insist on one table/file per real world thing.
One SQLite database per board with everything defined in SQL command text using application defined functions to bind to platform features. Customization can be performed deeply and at the grain of each board. You could allow enterprise customers to bring custom schemas or even code modules to inject and call. Would also make import/export absolutely trivial for any customer.
Or we can spend all our special innovation tokens on developing a goddamn database engine from zero...