NoDBA retweeted
JSON is burning your CPU!
Your API is slow. You blame the database. You blame the network. But the real bottleneck might be the language you are speaking.
JSON is not a data format. It is a text string.
Every time you send {"id": 12345}, your server pays a hidden 'Parse Tax.' Even with modern SIMD-optimized parsers, text processing faces architectural limits that binary formats do not.
Here is the rigorous engineering breakdown:
1./ The CPU Cost (state machine vs. arithmetic)
JSON (Text):
To read the number 12345, the CPU receives raw bytes. Even the fastest parsers (like simdjson) must implement a State Machine:
Scan for structural delimiters (: and ,).
Check for escape sequences (\).
the conversion:
Loop through ASCII characters, subtracting '0', multiplying by powers of 10, and summing. This involves branch mispredictions and memory lookups.
Protobuf (Binary):
It sends a Varint (for small numbers) or Fixed-Width (for large ones).
Fixed-Width (e.g., fixed32) => It is a raw memory copy (memcpy). Zero parsing.
Varint => It reads 1 byte at a time, checking the "Most Significant Bit" (MSB) to see if the number continues.
The Result => Decoding is effectively a few bitwise shifts and masks. For numeric-heavy workloads, this is mathematically guaranteed to be significantly faster than text parsing.
2./ The Bandwidth Cost (entropy vs. redundancy)
JSON:
[{"status": "active"}, {"status": "active"}]
You are sending the key "status" repeatedly.
Counter-argument => "But GZIP compression fixes this!"
The Rebuttal => GZIP reduces the Network bytes, but it increases the CPU cost. Your server now has to Serialize JSON -> Compress -> Send. The receiver has to Decompress -> Parse JSON. You are burning CPU to compress redundant text that shouldn't have been there in the first place.
Protobuf:
It separates the Schema from the Data.
The wire message replaces "status" with a Field ID (e.g., 1). [Tag: 1][Value: "active"]. This reduces the payload size before compression is even applied, saving CPU cycles on both ends.
3./ The Robustness Cost (schema-on-read)
JSON is "Schema-on-Read."
The receiver gets a blob. It hopes the ID is a number. Your code is full of runtime checks (if typeof(id) !== 'number'...) or you use a validation library (like Zod/Pydantic), which adds another layer of CPU overhead at runtime.
Protobuf is "Schema-on-Write."
It enforces a contract. While it doesn't catch logic errors, it guarantees Type Fidelity at the serialization boundary. You generally don't need expensive runtime validation libraries to check if an Integer is an Integer.
In a nutshell -
JSON is excellent for Public APIs (debuggable, easy). But for high-throughput Microservices, JSON is a tax.
Switching to gRPC/Protobuf isn't magic. It is simply moving the complexity from Runtime (parsing text) to Compile Time (code generation).
Happy Learning!
Follow @techNmak for more insights.
NoDBA retweeted
@chainguard_dev is committed to support MinIO under its EmeritOSS program: chainguard.dev/unchained/for…
NoDBA retweeted
MinIO's GitHub repo was just archived — officially no longer maintained as of Feb 12. If you're self-hosting S3-compatible storage, it's time to evaluate alternatives. What are you moving to? #selfhosted #MinIO #objectstorage
NoDBA retweeted
If you're streaming data into DuckDB, INSERT statements become a bottleneck fast.
DuckDB's Appender API bypasses the SQL layer entirely. No parsing, no query planning. You write directly to the columnar storage format, which means you can handle real-time ingestion without the usual speed/batch size trade-off.
How it works: Stream rows through a low-level API. Data caches in batches before writing to disk. You're essentially using a binary protocol instead of SQL strings.
Good for:
-Kafka consumers or message queue ingestion
-Log aggregation pipelines
-IoT sensor data collection
-Any scenario where data arrives continuously
The trade-offs:
It's order and type sensitive. You match columns exactly, no inference. One constraint violation fails the entire batch, no partial inserts. And you're writing to a single table per Appender instance.
Available in C, C++, Go, Java, and Rust. For batch ETL or small datasets, regular INSERT is simpler and fine. But for streaming? This is the tool.
Check out the docs: duckdb.org/docs/stable/data/…
NoDBA retweeted
Snowflake ML just got faster, now with @NVIDIA’s cuML and cuDF libraries built in for native GPU acceleration. No rewrites, just results.
Your scikit-learn and pandas workflows can now easily scale up and run on GPUs in Snowflake! We are excited to announce that Snowflake ML now comes preinstalled with @nvidia's cuML and cuDF libraries, delivering native GPU acceleration for popular data science tools like scikit-learn, pandas, UMAP, and HDBSCAN – no code rewrites needed.
Snowflake customers can now dramatically speed up ML model training and iterative exploration on massive datasets for use cases like topic modeling and genomics, all within a governed, unified platform. Benchmark results show up to 200x faster processing on GPU vs. CPU.
All the details: snowflake.com/en/blog/nvidia…
NoDBA retweeted
Google just dropped the Gemini File Search API (RAG-as-a-Service).
It allowed me to build a RAG chatbot in 31 min 🤯
No coding.
Here’s how it works:
NoDBA retweeted
Semantic layer is not a protocol. I think that the data community needs to get this idea out of their heads that a higher order DSL that can express the semantics of data. MDS tried selling us that promise and failed.
The real semantic knowledge of a business lives in unstructured docs and the minds of skilled domain experts. At best it's a giant, highly complex if-then-else of infinite depth. There is no way to codify this in a structured DSL.
youtu.be/Oq009TByyWc?si=Ti0_…
NoDBA retweeted
If you’re still sending raw JSON into your LLMs, you’re burning tokens, latency, and budget!
Try TOON (Token-Oriented Object Notation).
Clear like YAML, compact like CSV:
• 30–60% fewer tokens
• Up to 50% lower costs
• Shines for tabular data.
Free and Open source 🧵↓
NoDBA retweeted
We have done a big disservice to metadata. Because software systems could only properly express and process structured metadata, we limited ourselves to table/column definitions with some (largely failed) attempts at expressing metrics in a structured format - yaml or json. All other metadata was meant for human consumption only.
But that's merely scratching the surface of the vast amount of contextual information that accompanies data. This context is usually embedded in unstructured formats - PDFs, FAQs, internal docs, chats, meeting notes. Sure, you could surface this info in your favorite catalog tool but there was no way to actionize it or automate it. Until now.
AI agents with tool calls open up a completely different way to process this information. For instance, a properly configured AI agent can read a user doc (PDF) to understand the definition of a metric (with all its complex nuances) and then execute a SQL query that incorporates this definition.
Huge isn't even the word that describes the possibilities this unlocks.
NoDBA retweeted
Text to SQL conversion automation is still a big task and there are very few good open source models for this task.
Let's breakdown this -
>Text to SQL conversion models are basically nothing but encoder-decoder models with a multi-attention layer and a schema linking layer in between.
> The encoder processes both the user query and the database schema and generates contextual embeddings ( relation-aware encoding )
>Through schema linking, tokens in the query are aligned with corresponding schema entities
>The schema aware attention mechanism then allows the model to focus on relevant parts of the schema during decoding
> The decoder sequentially produces SQL tokens ( constraint-based decoding )
Where do these models lack ? -
>Most of the available models lack complex queries in training data itself and hence perform poorly on cross-domain or looped queries.
> Language and query requirement is not always correct from a normal user. Even spelling mistakes leads to wrong entry and causes issues during retrieval hence prompting is an important part in this task.
I personally worked on this in detail when I was making an end to end project, even made a synthetic data and tried training my own SLM but failed miserably and then went on to use an Open-source model.
If you want to deep dive into this, i would recommend reading these research papers first -
>LLM Enhanced Text-to-SQL Generation
>Next-Generation Database Interfaces:
>Text-to-SQL Parsing: Concepts and Methods
>RASAT: Integrating Relational Structures into Pretrained Seq2Seq Model
NoDBA retweeted
The PyData Amsterdam 2025 keynote “Minus Three Tier: Data Architecture Turned Upside Down” by Hannes Mühleisen is out now.
youtube.com/watch?v=DxwDaoUi…
NoDBA retweeted
Maintaining the right semantic context for text-2-sql is a delicate balance. Hence I keep thinking of it as semantic engineering.
I think AI use cases will force semantics to surface in the data models themselves, instead of just being an add-on yaml/json on top of existing data models.
Table names like "z_dep_cust1_new_backfill" will have to go out the door, if you plan to do any AI analytics on your data. No semantic models will help here.
Same with table design. Normalize your data too much and AI will hallucinate the joins. Denormalize too much and your context window will be forever struggling for space.
NoDBA retweeted
Designing a chat experience is interesting because conversational nuances are very hard to get right.
A simple Q and A loop soon starts feeling too rigid and robotic. To make it natural and human-like, a very fine-tuned workflow is needed.
For ex., when do you decide to ask a clarifying question, how do you make it contextual, how often do you do this in a long running conversation.
As with everything AI, a POC looks easy but it takes several weeks to get it right for real users.
NoDBA retweeted
Lots of database action this week. Yes, I have a new start-up @sydhtai with my PhD students (@lmwnshn + @17zhangw) using LLMs/ML to optimize almost everything in @PostgreSQL. The improvements are stunning!
@datadictum posted a new article on our approach: theregister.com/2025/10/22/c…
NoDBA retweeted
DuckDB Labs is looking for a Customer Support Engineer to help customers set up and operate DuckDB.
As Customer Support Engineer, you'll operate in the intersection of the DuckDB community, the DuckDB Labs customers, and the DuckDB core development team.
duckdblabs.com/jobs/customer…
NoDBA retweeted
📣 New blog post by Daniël ten Wolde!
🕸️ In this post, we show how to use DuckDB and the DuckPGQ community extension to analyze financial data for fraudulent patterns with the SQL/PGQ graph syntax that's part of SQL:2023.
📖 Visit duckdb.org/2025/10/22/duckdb… to read the post.
NoDBA retweeted
BOOOOOOOM!
CHINA DEEPSEEK DOES IT AGAIN!
An entire encyclopedia compressed into a single, high-resolution image!
—
A mind-blowing breakthrough. DeepSeek-OCR, unleashed an electrifying 3-billion-parameter vision-language model that obliterates the boundaries between text and vision with jaw-dropping optical compression!
This isn’t just an OCR upgrade—it’s a seismic paradigm shift, on how machines perceive and conquer data.
DeepSeek-OCR crushes long documents into vision tokens with a staggering 97% decoding precision at a 10x compression ratio!
That’s thousands of textual tokens distilled into a mere 100 vision tokens per page, outmuscling GOT-OCR2.0 (256 tokens) and MinerU2.0 (6,000 tokens) by up to 60x fewer tokens on the OmniDocBench.
It’s like compressing an entire encyclopedia into a single, high-definition snapshot—mind-boggling efficiency at its peak!
At the core of this insanity is the DeepEncoder, a turbocharged fusion of the SAM (Segment Anything Model) and CLIP (Contrastive Language–Image Pretraining) backbones, supercharged by a 16x convolutional compressor.
This maintains high-resolution perception while slashing activation memory, transforming thousands of image patches into a lean 100-200 vision tokens.
Get ready for the multi-resolution "Gundam" mode—scaling from 512x512 to a monstrous 1280x1280 pixels!
It blends local tiles with a global view, tackling invoices, blueprints, and newspapers with zero retraining. It’s a shape-shifting computational marvel, mirroring the human eye’s dynamic focus with pixel-perfect precision!
The training data?
Supplied by the Chinese government for free and not available to any US company.
You understand now why I have said the US needs a Manhattan Project for AI training data? Do you hear me now? Oh still no? I’ll continue.
Over 30 million PDF pages across 100 languages, spiked with 10 million natural scene OCR samples, 10 million charts, 5 million chemical formulas, and 1 million geometry problems!.
This model doesn’t just read—it devours scientific diagrams and equations, turning raw data into a multidimensional knowledge.
Throughput? Prepare to be floored—over 200,000 pages per day on a single NVIDIA A100 GPU! This scalability is a game-changer, turning LLM data generation into a firehose of innovation, democratizing access to terabytes of insight for every AI pioneer out there.
This optical compression is the holy grail for LLM long-context woes. Imagine a million-token document shrunk into a 100,000-token visual map—DeepSeek-OCR reimagines context as a perceptual playground, paving the way for a GPT-5 that processes documents like a supercharged visual cortex!
The two-stage architecture is pure engineering poetry: DeepEncoder generates tokens, while a Mixture-of-Experts decoder spits out structured Markdown with multilingual flair. It’s a universal translator for the visual-textual multiverse, optimized for global domination!
Benchmarks? DeepSeek-OCR obliterates GOT-OCR2.0 and MinerU2.0, holding 60% accuracy at 20x compression! This opens a portal to applications once thought impossible—pushing the boundaries of computational physics into uncharted territory!
Live document analysis, streaming OCR for accessibility, and real-time translation with visual context are now economically viable, thanks to this compression breakthrough. It’s a real-time revolution, ready to transform our digital ecosystem!
This paper is a blueprint for the future—proving text can be visually compressed 10x for long-term memory and reasoning. It’s a clarion call for a new AI era where perception trumps text, and models like GPT-5 see documents in a single, glorious glance.
I am experimenting with this now on 1870-1970 offline data that I have digitalized.
But be ready for a revolution!
More soon.
[1] github.com/deepseek-ai/DeepS…
NoDBA retweeted
The State of AI in SaaS:
SaaS is Dead, Long Live SaaS
This started as an analysis of Andrej Karpathy's excellent overview of AI's capabilities. Those who deeply understand this will make all the returns and everyone else will lose a lot of money.
"Ghosts" is a brilliant metaphor for what we've created. They're not animals, and they're definitely not human. They are imperfect replicas of us. Karpathy describes them as a "statistical distillation of humanity's documents".
AI channels that distribution more effectively than any human and can beat us at Go, schoolwork, analyzing medical images, and many well defined tasks. At the same time, it lacks the reward systems that humans use to improve including curiosity, empowerment, play, intrinsic motivation, and culture.
As a result, AI's capabilities are limited. If you watch how the best work gets done with AI, it happens in chunks where a human supervises the output and gives iterative feedback to the AI. Large scale autonomous agents are brittle and fail quickly. Watch anyone vibe code an application with any level of novel complexity.
AI also faces integration barriers into existing organizations. AI is not capable of pulling a lot of the levers you need to be effective like coordinating with multiple stakeholders, building trust, authenticity, and interacting with different modalities across time and space. You could argue that the average human doesn't either, but people know when they're interacting with an AI and don't allow it the same agency as they do to people. The most successful AI B2B companies actually need more humans to integrate what they've built (forward deployed engineers) than traditional B2B SaaS.
What's next?
Those who understand AI and its limitations will transform the industry.
Incumbents will be killed by those who know how to leverage AI. I've seen countless homepages talk about being the "AI platform for AI agents" but can't even string a demo together. Meanwhile they're trying to pitch a future where fully autonomous entities collaborate in parallel to write all the code and humans are useless. They will be the first to be replaced when they get surpassed by AI native companies.
The investors blindly throwing money into companies at 100x multiples are going to lose their money. I spoke with one of the most disciplined investors I know last week. They said they felt they had to play the game on the field even though they knew it didn't make sense. And this was from someone who is closer to the technology than 95% of investors.
On the other hand, companies who deeply understand AI will win everything. Cursor, Glean, Decagon, Sierra, Linear, Lovable, Replit, Bolt, and many AI natives are off to a great start.
While 90% of incumbents haven't adapted, it is possible. Figma, Notion, Vercel, Box, and Intercom have done a great job of tearing down what they have and rebuilding AI native products. They have teams who are close to the current capabilities of the models. They also understand their problem domain and as new capabilities come out know what capabilities will map well to what problems in what way. They are able to deliver on AI's promise to their customers. Whereas the majority of existing companies will die.
In analytics, the door is wide open. In spite of many of our competitors filling up their homepages with the text "AI", I haven't seen a single compelling demo. We're still working like it's 2015.
This will change. We have spent the last year at Amplitude rebuilding our team to be AI native. We've learned about what models are capable of, how to write prompts, and how to leverage evals for building great products. We've worked with our customers to see what gets used in practice and what doesn't. We are building a vision for the future of analytics. We are all in on AI at Amplitude.
Stay tuned for what's next. We're going to be fast and furious with AI products at Amplitude.