kiwicopple

5 ms·

31.
by kiwicopple 1y ago
An alternative viewpoint which we are pretty open about in our docs: > our technological choices are quite different; everything we use is open source; and wherever possible, we use and support existing tools rather than developing from
32.
by kiwicopple 1y ago
Great, thanks for this - we’ll make sure we have something in place
33.
by kiwicopple 1y ago
To add to your point: we didn’t file the patent. we acquired it (at a considerable cost) and we are working to make it freely available https://news.ycombinator.com/item?id=45196771
34.
by kiwicopple 1y ago
https://news.ycombinator.com/item?id=45200014
35.
by kiwicopple 1y ago
sam, I think you know me well enough now to know that we're open source through and through. my mistake - I should have been more involved in this process with the team. It is now Apache 2.0 which grants patent rights and can be re-lic
36.
by kiwicopple 1y ago
https://news.ycombinator.com/item?id=45200014
37.
by kiwicopple 1y ago
sorry about the confusion - I wasn't as involved in this process as I should have been. My fault. This is now fixed: https://github.com/orioledb/orioledb/pull/558 The code is now Apache 2.0 which grants
38.
by kiwicopple 1y ago
fixed - sorry about the confusion. https://github.com/orioledb/orioledb/pull/558 It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll ame
39.
by kiwicopple 1y ago
We are tracking the patches here: https://www.orioledb.com/docs#patch-set The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then i
40.
by kiwicopple 1y ago
The current license is PostgreSQL (which is OSI approved) We could also change to MIT/Apache but we feel PostgreSQL is more appropriate given our intentions to upstream the code
41.
by kiwicopple 1y ago
we will have something to announce in this space within a few months (if the atlasgo team are reading this feel free to reach out too)
42.
by kiwicopple 1y ago
Thanks for verifying the benchmarks. We’re close to a full RC, aiming for December Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
43.
by kiwicopple 1y ago
fwiw, this is not our m.o. - oriole was under development before we took on the maintenance/development. Our goal now is to ensure that it’s as F/OSS as possible given the pre-existing conditions
44.
by kiwicopple 1y ago
(Supabase ceo) I’ll revisit this with legal to try make it clearer. Our intentions here are clear - if people have examples that we can follow we will do what we can to make this irrevocable (even to the extent of donating the patent if&#x2
45.
by kiwicopple 1y ago
We have made our intentions clear with the core team but also haven’t pushed the agenda much - it’s too early. The conversations we have had so far are promising, we just need to make sure we approach it the right way. Projects like Oriole
46.
by kiwicopple 1y ago
> But I wonder if the core team, which is famously quite conservative about introducing big changes, sees this as too different to adopt as a replacement we respect the level of conservatism in Postgres and expect that this could take
47.
by kiwicopple 1y ago
we (supabase) are developing an open source vitess adaptation fwiw https://supabase.com/blog/multigres-vitess-for-postgres
48.
by kiwicopple 1y ago
pgactive uses logical replication so it should be compatible OOTB one of the possible enhancements Oriole could enable is multi-master (in the presentation here: https://www.orioledb.com/docs#solving-postgresql-wicked-prob..
49.
by kiwicopple 1y ago
It still requires some patches to the Table Access Method API which have been submitted upstream: https://www.orioledb.com/docs#patch-set
50.
Billions of Edges per Second with Postgres(onesparse.com)
5 points by kiwicopple 1y ago|1 comments
51.
by kiwicopple 1y ago
(Supabase ceo) We do not push devs not to do migrations - we would strongly prefer if everyone used migrations and declarative schemas. Especially at the scale that OP is at (see maturity model: https://supabase.com/docs&#
52.
by kiwicopple 1y ago
> reading my reddit comment about my argument for MCP --read-only it was great feedback, thank you!
53.
by kiwicopple 1y ago
(supabase ceo) > Supabase's official reply about this question is "I guess you can, but don't worry, RLS." Here is a more representative view of our official reply: https://supabase.com/docs/guide
54.
by kiwicopple 1y ago
(supabase ceo) > pushes very hard for RLS to increase adoption by non-technical users We are tailoring what we're doing for this audience. The challenge is that they appeared out of nowhere about 6 months ago and the LLMs that are
55.
by kiwicopple 1y ago
fwiw I couldn't access your airtable link, but I found this one online: https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N thanks for running the benchmarks, it helps to have external parties verifying the p
56.
by kiwicopple 1y ago
This release includes Asynchronous I/O (AIO): https://pganalyze.com/blog/postgres-18-async-io > Postgres has historically operated under a synchronous I/O model, meaning every read request is a blocking s
57.
Our Best Customers Are Now Robots(fly.io)
30 points by kiwicopple 2y ago|10 comments
58.
by kiwicopple 2y ago
Yes, once this is fully operational the idea would be that it is supported by the client libs or simply by the native libs provided by Automerge (or yjs, in the future)
59.
Show HN: Pg_CRDT – CRDTs in Postgres Using Automerge(github.com)
11 points by kiwicopple 2y ago|4 comments
60.
by kiwicopple 2y ago
A couple of years ago we shared[0] an experimental extension for CRDTs in Postgres. This was a good start, but it had a major limitation: CRDTs can be very chatty and so they quickly fill up the WAL. We just released a new version which sol

More ›