Keenable SELECT: A New Agent Paradigm for Querying the Web with SQL

When Search Becomes a SQL Query

In an era overflowing with AI Agent tools, a product called Keenable SELECT caught attention on Hacker News (48 points, 12 comments). Its core concept is striking: turning "searching the web" into a SQL statement.

For developers, SQL is the most familiar structured query language around. Keenable SELECT's clever insight is to treat the internet as a queryable "virtual data table," letting you retrieve, filter, and aggregate information from the web using SELECT statements — just like querying a database. At its heart, this design philosophy encapsulates Agent capabilities beneath an interface developers already know by heart.

From Natural Language Back to Structured Queries

Why Use SQL as an Agent Interface?

Over the past two years, mainstream AI search Agents (like Perplexity and various RAG systems) have almost universally relied on natural language conversation as their interaction model. Natural language has clear advantages — low barrier to entry, flexible expression — but its problems are equally obvious: unpredictable results, difficulty with programmatic calls, and no guaranteed output structure.

Keenable SELECT takes the opposite approach, using SQL's highly structured syntax to constrain search behavior. This delivers several immediate benefits:

• Structured results: Fields returned by SELECT are well-defined columns, naturally suited for writing to a database or feeding to downstream programs.
• High composability: Clauses like WHERE, ORDER BY, and LIMIT let you precisely control filtering logic and result count.
• Developer-friendly: No new DSL or complex API to learn — if you can write SQL, you can use it immediately.

This is, in a sense, a "return to roots": after large language models pushed everything toward natural language, re-imposing structure to govern Agents actually makes systems more predictable and easier to integrate into engineering workflows.

What Role Does the Agent Play Behind a SQL Query?

Interestingly, SQL is just the interface layer — the actual work is still done by the AI Agent underneath. When you write a query, the system needs to:

1. Parse the SQL semantics to understand what you're looking for;
2. Translate the query intent into real web search and scraping actions;
3. Extract structured data matching the selected fields from unstructured web page content;
4. Return results according to the SQL constraints.

Step 3 — mapping messy web content into a clean data table — is precisely where large language models shine, and it's also the core technical challenge of products like this.

This architecture is conceptually aligned with the idea of Table-Valued Functions (TVFs) in software engineering. In traditional databases, table functions let developers wrap a piece of computation logic into a queryable virtual table, with callers never needing to know the internal implementation. Keenable SELECT works the same way — web_search(...) looks like a table, but underneath it's a full search-scrape-extract Agent pipeline. This design closely resembles PostgreSQL's Foreign Data Wrapper (FDW) mechanism: FDW lets users query external data sources (CSV files, REST APIs, other databases) using standard SQL, with the system handling protocol translation internally. Keenable SELECT is essentially registering "the internet" as an FDW data source, with AI standing in for the hand-written connector adapters of a traditional FDW. Understanding this analogy helps assess its capability boundaries: FDW's classic pain points — predicate pushdown efficiency and unpredictable JOIN costs — apply here as well.

What Real Pain Points Does Keenable SELECT Address

The "Search Gap" in Data Pipelines

In many data engineering scenarios, developers need to pull real-time information from the public web — things like "prices for a certain product category across e-commerce platforms," "recent job listings from a specific company," or "recent news on a given topic." The traditional approach is to write scrapers, clean the data, and load it into a structured store — a pipeline that's long and fragile.

Keenable SELECT aims to compress this entire pipeline into a single SQL statement. In theory, you could write:

SELECT title, price, url
FROM web_search('wireless headphones under $100')
WHERE price < 100
ORDER BY price ASC
LIMIT 10;

And get clean, structured results back directly. For teams that need to feed web data into an existing data stack (like a data warehouse or BI tools), the appeal is obvious.

What Programmable Search Really Means

At a deeper level, "SQL-ifying" search means making it callable by programs, triggerable by cron jobs, and embeddable in larger automation workflows. Compared to manually asking questions in a chat window, this is a meaningful upgrade toward automation. You can wire it into Airflow, plug it into a backend service, and make "fetching information from the web" a standard node in a data pipeline.

RAG (Retrieval-Augmented Generation) is currently the dominant knowledge-acquisition paradigm in AI applications: a retrieval system first finds relevant document chunks, which are then fed as context to a large language model to generate an answer. Standard RAG, however, typically relies on a pre-built vector index and can only retrieve already-indexed content — it's powerless against real-time web information. Keenable SELECT represents a class of "real-time RAG" or "open-domain retrieval" thinking — every query reaches directly out to the public internet, bypassing the index-building step entirely. This gives it a timeliness advantage over traditional RAG, but at the cost of losing the semantic recall capabilities and amortized cost benefits that vector indexes provide. Combining both approaches — using a SQL interface to trigger real-time scraping while vector-caching the results — may be the direction this category of products evolves toward.

Technical Challenges and Open Questions

Despite the elegance of the concept, products like Keenable SELECT face several unavoidable challenges:

• Data extraction accuracy: Reliably mapping free-form web pages to a fixed schema is a long-standing hard problem in NLP. Misextracted fields, omissions, and hallucinations can all directly corrupt query results.
• Balancing real-time performance and cost: Every query may trigger live web search and LLM inference — controlling latency and cost is a very real concern.
• The limits of SQL expressiveness: There's a natural tension between the ambiguity of web information and the precision of SQL. When the query intent itself is fuzzy, SQL's strict syntax can become a constraint rather than an asset.

The level of discussion on Hacker News reflects the developer community's mix of curiosity and caution toward this kind of "structured Agent interface."

Hallucination deserves particular attention in this context. In conversational AI, hallucination typically manifests as fabricated facts that users can often catch with common sense. But in structured query scenarios, hallucinations appear as "numbers that look plausible but are actually wrong" — for instance, a price field filled in by the model from prior knowledge rather than actually scraped, or a URL generated rather than crawled. Once these errors enter a data pipeline, they propagate silently, contaminating downstream analysis and making them extremely costly to debug. This is why products in this space must engineer strict provenance mechanisms: every returned field should carry a precise citation back to the original web page (URL + text offset), allowing downstream systems to independently verify results rather than blindly trusting the model's extractions.

Another Possible Direction for Agent Interface Design

Keenable SELECT's greatest value may not lie in the product itself, but in the interface design philosophy it proposes: AI Agents don't have to manifest as chat conversations. They can be hidden beneath abstractions developers already know well — a SQL statement, a function call, an API endpoint.

As Agent capabilities gradually become infrastructure, how to "engineer and package" them will become a critical question. Querying the entire web with SQL is just one particularly illuminating example in this broader exploration. It reminds us: the best AI products often pack powerful capabilities into containers users already know by heart.