This feels like satire.<p>and written by someone who should have spent more time studying the
history of database systems.<p>> Imagine a world where the majority of your backend logic is seamlessly embedded within the database itself<p>This is not a good idea.
It has been done many times and never quite caught on because it is not a good idea.<p>From a security perspective it is a nightmare.<p>Or if you do put all the correct isolation around the code
to protect the database, then you have basically created
an "app server" (old term) inside a database, and it would
happily, run outside of the database since in essence it is already
doing so.
Not Open Source (in an OSI way):<p><a href="https://github.com/surrealdb/surrealdb/blob/ed60a35b9b539e1b4be0725d909ba9d83e45ce07/LICENSE">https://github.com/surrealdb/surrealdb/blob/ed60a35b9b539e1b...</a>
> Imagine a world where the majority of your backend logic is seamlessly embedded within the database itself<p><i>thinks of Oracle APEX</i><p><i>thinks of IBM AS400</i><p><i>shudders</i>
Fireship did a 'SurrealDB in 100 seconds' in case anyone would like a quick video summary: <a href="https://youtu.be/C7WFwgDRStM?si=va17q7zagn4lIoi3" rel="nofollow noreferrer">https://youtu.be/C7WFwgDRStM?si=va17q7zagn4lIoi3</a>
It benches very very slow and no options to horizontally scale outside of manual sharding.<p>API has a cool design though.<p>The dev team needs to look at perf before the complexity hole gets too insane if it hasn't already.
Strong vibes from RethinkDB. I hope SurrealDB will have a different fate, I'm a big big fan of live queries and change feeds and don't like most existing implementations.
My biggest concern with SurrealDB is the license, otherwise I'd be very interested in adopting it.<p>I know the license is okay, but from my reading of it, sounds like if SurreaDB really wanted to shut you down they could.<p>Otherwise, I find the architecture of it to be beautiful and compelling.
“Imagine a world where the majority of your backend logic is seamlessly embedded within the database itself.”<p>Don’t need to. Majority of my work is de-coupling systems “designed” around this idea.<p>Why can’t the database be the database, the backend be the backend, etc ? You can’t have a toolbox full of multi use tools. Sometimes you just need a fucking Phillips head screwdriver.
Is there any trick to implement live updates in a scaleable way? In the limit for a naive implementation, every mutation would have to check every subscriber to see if the change is relevant which seems like it would cause large bottlenecks for writes.
While I applaud any attempts to innovate in this area, I'd be more interested in seeing the opposite approach - integrating persistent storage in a programming language. If we already have default implementations of dictionaries, linked lists, and other in-memory data structures in programming languages, why not have default implementations of permanent data structures such as object collections and KV-stores?
1.0 version but <a href="https://github.com/surrealdb/surrealdb/issues/1548">https://github.com/surrealdb/surrealdb/issues/1548</a> is still open :)
Is it a database where the only date/time type is a melting clock, and a join is defined as “the chance encounter of a sewing machine and an umbrella on an operating table”?