Like other tech disrupted crafts before this, think furniture making or farming, that's how it goes. From hand-made craft, to mass production factories (last couple of decades) to fully automated production.
The craft was dying long before LLMs. Started in dotcom, ZIRP added some beatings, then LLMs are finishing the job.
This is fine, because like in furniture making, the true craftsmen will be even more valuable (overseeing farm automation, high end handmade furniture, small organic farms), and the factory worker masses (ZIRP enabled tech workers) will move on to more fulfulling work.
Periodic objectives x customer results then GPT-5 scoring pull requests, etc. against them roughly aligned to that period. I.e. it scores higher if code is used by and produces value for customers.
CedarDB focuses on being a high-performance HTAP database whereas Spice's was built from day 1 to enable high-peformance data and search for data-intensive applications and AI.
So Spice natively has data acceleration, federation, hybrid-search (vector + BM25 full-text-search), and LLM inference in the core runtime so you can zero-copy data across them, which you would not normally see in a database like CedarDB.
Like most things, all measures fail point in time and on short time horizons, but law of big numbers and trends can be useful. I.e. compare yourself (on almost any measure) to yourself in your most productive period.
We reviewed our metrics for period-on-period comparisons at 1, 2, 3, 4 years and the numbers are surprisingly consistent for each person, and across similar productive engineers.
Like in the article, if you can apply a semantic score across years of data, it gives you a pretty good idea.
Hi HN, we’re Luke and Philip, founders of Spice AI. Today, we’re announcing Spice.ai OSS 1.0-Stable, a portable, single-node data query and LLM-inference engine built in Rust.
We introduced the very first POC of Spice.ai OSS on ShowHN in Sep 2021 as a runtime for building AI-driven applications using time-series data!! [Insert, it’s been 87-years meme].
One of the hard lessons we learned was that before we organizations could use AI effectively, they needed a much higher level of data readiness. Our customers told us they wanted to adopt AI and technologies like Arrow, Iceberg, Delta Lake, and DuckDB but simply didn’t have the time or resources (and were struggling to keep up), so we focused on making it super easy and simple to use them. We rebuilt Spice from the ground up in Rust on Apache DataFusion, and launched on ShowHN in Mar 2024 as a unified SQL query interface to locally materialize, accelerate, and query datasets sourced from any data source.
It’s designed for developers who want to build fast, reliable data-intensive and AI apps without getting stuck managing ETL pipelines or complex infrastructure.
That release was just the data foundation and today, we’re announcing Spice.ai OSS 1.0-Stable that includes federated data query, acceleration, retrieval, and AI inference into a single engine—now ready for production deployments across cloud, BYOC, edge, or on-prem.
Spice supports accelerating federated queries across databases (MySQL, PostgreSQL, etc.), data warehouses (Snowflake, Databricks, etc.), and data lakes (S3, MinIO, etc.). It materializes datasets locally using Arrow, DuckDB, or SQLite for sub-second query times and integrates LLM-inference and memory capabilities and a purpose-built data-grounding toolset that includes vector and hybrid search, Text-to-SQL/NSQL, and evals to ensure accurate outputs.
The Model Context server is similar to what we've built at Spice, but we've focused on databases and data systems. Overall, standards are good. Perhaps we can implement MCP as a data connector and tool.
Being such a core component, we want developers to be completely comfortable integrating and deploying the Spice runtime in their applications and services, as well as running Spice in their own infrastructure.
In addition, Spice OSS is built on other great open-source projects like DataFusion and Arrow, both Apache 2.0, and DuckDB (MIT), so being permissively licensed aligns with the fundamental technologies and communities it's built upon.
We expect to release specific enterprise control-plane services, such as our Kubernetes Operator under a license such as BSL.
Spice AI | SWE & DevRel | FT | ONSITE (Seattle, Seoul), REMOTE (Australia)
Spice AI is the creator of the Spice.ai open-source project, a query-engine and ML inferencing runtime built in Rust on DataFusion.
Hiring experienced Rust, distributed systems, data systems, and database engineers and DevRel.
ShowHN: https://news.ycombinator.com/item?id=39854584
Details: https://spice.ai/careers
In addition, Spice manages the materialization for you. In the DuckDB-only case, you'd have to do a COPY FROM [remote postgres] to [local postgres] manually every time, and manage the data lifecycle yourself. That gets even more complicated if you want to do append or incremental updates of data to your local materialization.
DuckDB is awesome. As an OLAP columnar-store database it excels at certain operations, like aggregations. If your use-case is row-based lookups where an OLTP database would perform better, you now get a choice of engine, while still having a single place to access your data from your app.
Originally, we only supported DuckDB in our cloud product Spice Firecache, but actually lost a customer because their use-case was optimized for an OLTP DB. Now, you can get a choice... down to the dataset level and still be able to join across them in a single query. With Spice, you can load both SQLite and DuckDB together in the same process for local materialization and acceleration.
Finally, Spice OSS does more than just data query. You can read about the vision to power AI-driven applications by co-locating data with models at https://docs.spiceai.org/intelligent-applications.
Spice supports what DataFusion supports, which is generally yes but there is still work to do to push down more queries to TableProviders. For example, joins within a single source are not yet pushed down to the underlying provider.
You can write a single query across many data sources which is what we show in the demo on the Git repo.
Yes, in terms of federated queries, there are similarities, but Spice is designed to be much smaller, faster, and lightweight (single-binary, 140MB) so you can run it next to your application as a sidecar, or eventually even in the browser. Spice also gives you more options and flexibility for materialization, so you can choose where and how to store local materialized data.
Dremio is awesome. We've followed the Dremio journey from one of Jacques' original talks a couple of years back. Dremio's idea of caching tiers and reflections is powerful for performance.
Spice takes it further and provides flexibility for materialization, giving you full control over where that materialization exists (same machine, same pod, same network, same cluster, same region, etc.), what engine/processing (OLTP - SQLite/PostgreSQL, OLAP - DuckDB/Arrow) it uses and what tier (in-memory, attached NVMe, etc.) to store it down to the dataset level.
We believe blockchain data is one of the most interesting time-series datasets to work in developing an AI-driven application platform, because it's continuous, well-structured, has many applications, and is open to index. Regardless of views on crypto, from a purely technical/data feed perspective, it's quite useful for testing time-series systems.
https://spice.ai