This is my expectation as well. At CIDR this year there was a paper that presented an implementation of SQL/PGQ in DuckDB, and it outperforms Neo4J in a few selected benchmarks [1].
> The ANN index IVF implemented in pgvector has very poor performance, with only around 50% recall.
My understanding is that this mostly due to the default settings that pgvector uses (nprobes = 3) and not due to the usage of IVF. The recall would improve significantly with better defaults. This of course would also increase the latency of vector searches, but that is the trade-off of using IVF instead of HNSW (worse latency at high recall, but much lower storage/memory costs).
But you don't have to write map-reduce jobs at all? You can just write SQL queries or Pandas programs, and they automatically get parallelized by Databricks. Databricks is a data warehouse (just like Snowflake).
TIS-100 brought back some of the same joy that I had when I began with programming many years ago. Since then programming has become boring for me, but the weird limitations of TIS-100 almost made it feel like I was starting fresh again. I loved learning tons of small tricks that I could apply to beat the harder levels.
2-day delivery would be uncompetitive in The Netherlands. Next day delivery is the standard for webshops here, and most offer same day delivery as a paid upgrade when you either order before noon or live in a large city.
Wow, $14.99/month is a stark difference with the €2.99/month that they charge for a Prime subscription here in The Netherlands. I wonder if they will increase the subscription fee here to the same level once they reach the desired market share in the video streaming and e-commerce spaces here.
For those wondering what the differences between Raft and Paxos are: I can highly recommend the following paper https://arxiv.org/abs/2004.05074 It presents Paxos similarly to how Raft was originally presented.
You might be interested in this paper [1] which presents Paxos in the same way as Raft is presented in the Raft paper. In my view it really illustrates that most of the simplicity of Raft comes from its excellent presentation and not necessarily from its algorithmic simplicity.
(Multi-)Paxos and Raft are incredibly similar. I would even argue that Raft is just a variant of Paxos in the same way that e.g. Fast Paxos and EPaxos are variants of Paxos. Most of the Raft algorithm is identical to the Paxos algorithm. The main difference between the two algorithms is how leadership election works. In my view the main reason why Raft is considered to be simpler is because it was presented in a really clear paper. Paxos becomes equally simple when using a similar representation as used in that paper. See this paper: https://arxiv.org/pdf/2004.05074
Netflix is also the most expensive service that I am subscribed to. Netflix is €14 and Amazon Prime is only €6. I basically only watch Netflix for a few of their originals (which are arguably aren't that great).
When was the last time you used Databricks? You should definitely try it again. Their product offering has improved a lot in the past few years.
> broad feature set
My experience is that the feature sets of Snowflake and Databricks are very similar. Both have time travel support. Snowflake has materialized views, but Databricks has Delta Live Tables. Databricks has a distributed Pandas API, but Snowflake recently introduced Snowpark. Databricks also has autoscaling and they recently launched a serverless offering that makes autoscaling super fast aswell.
Agreed! GCP should be broken up as well. It is incredibly unfair to third party services that Google is both supplying the platform and the competing services. This is probably a bigger problem on AWS though.
Apple has filed a court case to block the publication of a report. Obviously the contents of the report will be discussed as part of the hearings. So if the hearings were public then the contents would become public as well, which would make the court case pointless. Hence the private hearings.
Comparing Apache Beam with Stripe's API is unfair in my opinion. Apache Beam can be operated outside Google Cloud, but the Stripe API is only useful for Stripe customers (as mentioned by the author). I don't think it's weird that a company provides more support to paying customers. The author should have raised the issue with Google Cloud's support team, instead of creating a Jira ticket for Apache Beam.
[1] https://www.cidrdb.org/cidr2023/papers/p66-wolde.pdf