11–20 of 56 posts
> Imagine a world where the majority of your backend logic is seamlessly embedded within the database itself thinks of Oracle APEX thinks of IBM AS400 shudders
My biggest concern with SurrealDB is the license, otherwise I'd be very interested in adopting it. I know the license is okay, but from my reading of it, sounds like if SurreaDB really wanted to shut you down they could. Otherwise, I find the architecture of it to be beautiful and compelling.
Unless you're operating a "database service", a well defined term (in the license) that excludes almost every use-case A “Database Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work by creating tables whose schemas are controlled by such third parties. I don't see how SurrealDB could shut you down?
Not Open Source (in an OSI way): https://github.com/surrealdb/surrealdb/blob/ed60a35b9b539e1b...
Is it claiming anywhere to be open source? I've heard an interview with the creators and they seemed pretty open about which aspects where open source and which aspects where shut down? I could be missing something from their branding but I'd rather see projects with non-open source licenses from the beginning that bait-and-switch license change when they want to become profitable. (Although, I'd much rather just see…
and written by someone who should have spent more time studying the history of database systems.
> Imagine a world where the majority of your backend logic is seamlessly embedded within the database itself
This is not a good idea. It has been done many times and never quite caught on because it is not a good idea.
From a security perspective it is a nightmare.
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.
Earlier quoted context omitted.
Unless you're operating a "database service", a well defined term (in the license) that excludes almost every use-case A “Database Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work by creating tables whose schemas are controlled by such third parties. I don't see how SurrealDB could shut you down?
So if you create schemas on the fly, you cannot? Why would I use such a db?
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.
The strategy is to break the subscription up into listens based on the read-set ranges of the query. Then you put the individual read-set ranges into a system table that you index. Finally when writes happen, you notify all queries who's read-set intersects with the write-set.
For example, say I have a query `SELECT * from block WHERE parent_id = X AND last_modified_at > Y`.
This query might create two subscriptions for its read sets:
{ query_id: Q, table: block, column: parent_id, min: X, max: X }
{ query_id: Q, table: block, column: last_modified_at, min: Y, max: Infinity }
We can find our subscriptions to notify by doing queries like these:
SELECT query_id FROM subscription WHERE
table = block
AND (
(column = id
AND min = new_block.id
)
OR
(column = parent_id
AND min = new_block.parent_id)
OR
(column = last_modified_at
AND min = new_block.last_modified_at)
)
I'm sure there's a lot of details and optimizations you can do on top of this; finding the right read sets seems pretty tricky for complex queries. Plus stuff like batching/debouncing, etc.