Earlier quoted context omitted.
It’s not quite the same thing but nearby: I built a EAV secondary index system on top of Postgres to accelerate Notion’s user-defined-schema “Databases” feature about a year ago. By secondary index, I mean the EAV table was used for queries that returned IDs, and we hydrated the full objects from another store. We’d heard that “EAV in Postgres is bad” but wanted to find out for ourselves. Our strategy was to push the…
Does postgres not have the ability to hint or force indexes? Long long time ago, I found that quite helpful with MySQL.
Show HN: InstantDB – A Modern Firebase
161–170 of 308 posts
Re: Show HN: InstantDB – A Modern Firebase
#162I saw the mention of Google's CEL for authorisation and permission, however would like to know a little about security. Apart from the appId, can I restrict call to db by domain etc. Firebase has protection on such things . somebody should not just take the appId and start calling db.
Re: Show HN: InstantDB – A Modern Firebase
#163Is the datalog engine exposed? Is there any way to cache parsed queries? Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? Or is it on the roadmap? I have fairly large and overlapping rules/queries. Is there any way to store parsed queries and combine them? Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as…
> Is the datalog engine exposed? Is there any way to cache parsed queries? We don't currently expose the datalog engine. You _technically_ could use it, but that part of the query system changes much more quickly. Queries results are also cached by default on the client. > Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? There's no shorthand for recursi…
If it was I would never use another database again.
I think the amount of people coming from datascript/datomic who have to work in js and would prefer to use datalog instead of learning a new query language is big.
Re: Show HN: InstantDB – A Modern Firebase
#164I really want an ActiveRecord-like experience. In ActiveRecord, I can do this: ```rb post = Post.find_by(author: "John Smith") post.author.email = "john@example.com" post.save ``` In React/Vue/Solid, I want to express things like this: ```jsx function BlogPostDetailComponent(...) { // `subscribe` or `useSnapshot` or whatever would be the hook that gives me a reactive post object const post = subscribe(Posts.find(prop…
Re: Show HN: InstantDB – A Modern Firebase
#165Re: Show HN: InstantDB – A Modern Firebase
#166I saw the reference to “apps like Figma” and as one of the people that worked on Framer’s (also a canvas based app) database which is also local+multiplayer I find it hard to imagine how to effectively synchronize canvas data with a relational database like Postgres effectively. Users will frequently work on thousands of nodes in parallel and perform dragging updates that occur at 60 FPS and should at least be propag…
About the synchronized data though I think it's not about the database but the data types designed to sync the data? I worked on multiple-player canvas games and we didn't really care that much about relational db or document db, they worked both fine. I would love to know what's the difference and the challanges.
Re: Show HN: InstantDB – A Modern Firebase
#167For those looking for alternatives to the offline first model, I settled on PowerSync. Runner up was WatermelonDB (don't let the name fool you.) ElectricSQL is still too immature, they announced a rewrite this month. CouchDB / PocketDB aren't really up to date anymore. Unfortunately this area is still immature, and there aren't really great options but PowerSync was the least bad. I'll probably pair it with Supabase…
Co-founder of PowerSync here. Would love to hear what you would like to see improved in PowerSync :) Thanks!
Re: Show HN: InstantDB – A Modern Firebase
#168Earlier quoted context omitted.
Yes, reading the essay, that seems like the only "red flag" to me, the rest sound like a dream db. Not being able to leverage permission rules to optimize queries (predicate pushdown) seems like too big a compromise to me. It would be too easy to hit pathological cases, and the workaround would probably be something akin to replicating the permission logic in every query. Is there any plans to improve this?
Yes, in the near future we plan to convert CEL expressions to where clauses, which we attach to queries. This would push permissions to the query level, like postgres RLS.