> Well, yes, it is: most startups don’t pay income tax because most startups aren’t profitable! Indeed, startups seek investment because they have costs long before they have revenue, let alone gross profit — let alone income. This is by design: profitability is a lagging indicator of product/market fit (the adventure in venture capital is investing long before the business has materialized!).
Venture Capital is one of the greatest engines of growth, and fitting for the vast majority of early stage tech companies, it is interesting to see how changes in business economics may result in niche, differing capital structures. Eg. Companies which sell RL envs have vastly different economics than a food delivery app.
Little known fact is that POSTGRES used to have built-in Time Travel [1].
It was deprecated as the performance hurdle was significant.
This seems to utilize logical WAL replication and some form of dependency generation based on proxying a transaction's reads.
Managed Neon (Acquired by Databricks) also offers time travel [2].
One of the biggest challenges with this kind of solutions is handling ACID, OCC and/or HW failures correctly, Sometimes it requires an whole new language! [3]
The consistency guarentee assuming repeatable read or higher on each shard is parallel snapshot isolation, which is technically still higher than postgres read committed.
If you have serializable on each shard and you chop transactions so you have no cross shard transactions, the application is technically still serializable, it just behaves like two independent deployments of the application for different shards
It's probably magnitudes of token chatter and inter-agent coordination/consideration. Not that I'd want to read any of it but getting some hands around the statistics would be cool.
As far as I can tell, incremental the library aims to solve the problem of partially hydrating a computation graph when source data is altered. This approach is similar to the one pursued by (well designed) build systems and is common in the FP world. [2] This has many use cases and is very cool.
In addition, in the sphere of incremental computation, there exists Differential Dataflow, Timely Dataflow (adjacent), and DBSP. Systems like Feldera are built on DBSP. Materialize is lead by some DD guys.
Personally, I am pursuing an orthogonal approach specifically for the problem of financial data and financial workloads, There exists huge, very important problems to solve! [1]
Your site has a bunch of marketing copy, trademark symbols, and a link to pay you $2k/mo, but zero technical detail and is broken on mobile. It gives vibe coded.
The benchmark of 2m black-scholes evals/sec is meaningless without additional context. Also seems a couple orders of magnitude slower than what I’d expect even for a single core. What exact transformations are being done, and what’s the throughput in GB/sec? Is it multi threaded? Benchmark against the equivalent query in kdb+ and ClickHouse?
What additional technical detail would you be interested in?
> Also seems a couple orders of magnitude slower than what I’d expect even for a single core.
1) it's more than 2m/s on a MacBook AIR
2) Most of the latency is networking. This was a preliminary setup with a client / server over websockets where the book of 1m contracts combination of (strike, exp_date). Each insert only after a corresponding query has been returned (over the wire) from the previous insert. I can agree the eval isn't great; as in, the throughput is much higher.
Check out https://github.com/ila/openivm which implements a very large scope of aggregations as incremental operations in an SQL-to-SQL compiler, and extension for duckdb that automatically maintains a materialized view
reply