A "relation" is the fundamental concept in relational databases. When they say "set based" they really mean "relation based" as far as I can tell from their sit

A "relation" is the fundamental concept in relational databases. When they say "set based" they really mean "relation based" as far as I can tell from their site. So this is essentially a relational database that replaces SQL with their bandicoot language. Stralep asked "But why are relational types limited only to be composed of primitive types?". Well, most SQL-based databases are like that, and you link separate relations together using foreign keys. It would be an interesting feature if they made it hold hierarchies of objects, but then, that reduces the ability to perform relational algebra operations because you'd be hiding parts of your relations in those nested structures. That becomes an SQL vs NoSQL debate. Object Store vs. relational data. I notice that they have a very simple distributed mechanism. You can have many instances of "executors" (the interpreter / computation handler) and of "volume" (data storage and access), but just one transaction manager. Seems pretty simple. What I want to know is how this compares to the speed and scalability of MySQL. Do I want to start replacing my MySQL servers with bandicoot? It also occurred to me that you essentially have a stored-procedures-only system here. You can call any function via http but you can't execute arbitrary queries. Aside from that, I don't see any built-in security other than placing this behind a firewall if you want to limit it to only back-end server use in your PHP/Ruby/Java/Arc/etc. applications. You will have to edit the bandicoot code file in conjunction with your web app code to incorporate all the queries you need, but that separation of concerns could be considered a good thing.