lukekim

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 is a super cool project, we're fans!

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.

We’d love for you to check it out on GitHub, try it, and share your feedback: https://github.com/spiceai/spiceai

Thank you!

[1] Spice.ai OSS v0.1 announcement: https://news.ycombinator.com/item?id=28449182

[2] Spice.ai OSS rebuilt in Rust: https://news.ycombinator.com/item?id=39854584

You also have to run it as admin. If you don't, it tries to auto-update every day and when it can't presents a big, obnoxious red banner.

[1] https://x.com/WarpSpeedDan/status/1811447481047097788

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.

[1] https://github.com/spiceai/spiceai

We chose Apache 2.0 for the Spice OSS runtime.

TL;DR: Data-plane Apache 2.0, control-plane BSL.

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.

[1] https://github.com/spiceai/spiceai

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

Also anecdotal, but we (Spice AI) see more requests for Iceberg, but in practice more deployments of Delta Lake.

Thanks! Feedback and GitHub issues welcome!

Yes, it's on the backlog and we'll prioritize as we see demand as with https://github.com/spiceai/spiceai/issues/999.

You're right, and that might be a good choice if you wanted to deploy and operate an additional PostgreSQL server locally.

## Using DuckDB:

app -> duckdb -> network -> remote postgres (data) | local postgres (materialization)

## Using Spice:

app -> localhost gRPC/HTTP -> [Spice <duckdb|sqlite>] -> network -> [postgres|S3|snowflake|etc]

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.

Thank you! Much appreciated.

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.

Thank you!

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.

We also have a Grafana plugin we'll continue to improve to make it super easy to connect to Grafana, and Spice has a metrics endpoint and example Grafana dashboard for monitoring itself https://github.com/spiceai/spiceai/blob/trunk/monitoring/gra...

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.

Actually, we posted the original vision in Sep 2021 at https://blog.spiceai.org/posts/2021/09/07/introducing-spice.... for AI-driven applications and discussed needing a good source of data at https://blog.spiceai.org/posts/2021/12/05/ai-needs-ai-ready-....

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.

Yes, we're huge fans of DuckDB, Mark, Hannes and the team.

What we've found is sometimes you want to materialize data in an OTLP DB, so what Spice gives you is the choice to store some datasets in DuckDB and some in something like SQLite/PostgreSQL and join them together in a single SQL query, so you can get the best of both worlds.

Thank you!

Thank you!

You can also do this manually with quicktype.io. We've found it useful from the number of languages it supports.

Thank you! Yes, that's what we are currently doing, however the long term direction is to move as much of the codebase to Go/Rust as possible to be portable across hosting environments as possible.

Thanks for taking the time to write up this feedback. Yes it's obvious now we need to improve the examples, and I like your structure. Perhaps you can help us.

Would love to chat more.

PM me on Twitter at https://twitter.com/0xLukeKim if you are interested.

Thanks for taking the time to write up this feedback. Great point. We've been coding for three months, and are still figuring out exactly how to message the project.