ApertureData

Foundational Data Layer for AI: Combine scalable vector search with memory-optimized graph and multimodal data management

[ApertureData @ApertureData]

An agent picking dinner needs to know what fits under 600 calories, and how it splits by cuisine and diet, before it reads any recipe.

In ApertureDB, group returns per-value counts for the properties you list, with an average per group, without fetching the records:

"constraints": ["$calories", "<=", 600],
"results": {"group": ["cuisine", "diet"], "average": "calories"}

The agent picks the next filter from the counts.

Docs:
https://t.co/W5GLyKZOSm

[ApertureData @ApertureData]

Vector search plus a simple filter, like ownership, is fast and often enough for RAG.

When relevance depends on relationships, walk the knowledge graph first: customer, model, part, manual. Then rank only those manuals by similarity to the photo of the failed part.

Embeddings and the graph live in one database, so moving from simple RAG to graph RAG is a change to the query, not the database.

Docs:
https://t.co/mwewuxunZ2

[ApertureData @ApertureData]

ApertureDB supports ACORN for filtered vector search on the HNSW engine. It finds neighbors that satisfy property, label, and relationship constraints. Approximate, so results can differ from the default exact search.

Off by default. Set filtered_knn to true, with k_neighbors.

Docs:
https://t.co/zfdIc1lb8A

[Vishakha Gupta-Cledat @vishakha041]

Aperture Nexus does not decide what your agent remembers. That was deliberate, and we're now asking whether it's what people building agents actually want.

Right now the API does the persistence work. It stores a full video, adds embeddings, and writes the record. It does not decide what to summarise, what to retain, or when to prune. The agent calling it makes those decisions. We don't add our own reasoning or memory-management logic on top.

The layer still gives you structure. Every commit, context and session becomes a knowledge graph entity the moment it is written, with provenance on each one. Memory is scoped to users and sessions. It is model-agnostic, so you bring your own embedding model keys or provider.

The argument for leaving retention to the agent is that the agent knows its task. A coding agent and a support agent shouldn't forget the same things. The argument for ready-made behaviour is that otherwise each team ends up writing its own summarise-and-prune logic.

We're considering design-partner work to settle this. If you're building agentic applications: which memory decisions would you hand to the memory layer, and which would you never let it make for you?

[ApertureData @ApertureData]

ApertureDB array properties can be indexed. An array index can speed up membership checks and selected-element lookups.

["red", "in", "$colors"]
[{"at": ["$colors", 0]}, "==", "red"]

Docs:
https://t.co/5tEciJtvzT

[Vishakha Gupta-Cledat @vishakha041]

In a contract, the clause that got overridden and the clause that replaced it mean almost the same thing. To an embedding model, they're neighbors.

That was the hard part when we built a legal agent. The question was never "which passage looks like this one." It was "which clause is in force right now, and what did it replace?" Similarity search can't answer that, because the superseded version and the current one are close to identical in meaning. The amendment history and the relationships between clauses are what tell them apart.

What got us the right answers:

- Curating the graph structure so each amendment points to what it overrides
- GraphRAG over that graph to follow the chain to the version that's current
- The multimodal-native API in ApertureDB (@ApertureData) to pull the exact paragraphs from the source documents

The graph relationships, the metadata, the embeddings and the documents themselves all sit in one database. The traversal and the retrieval happen in the same place, so we didn't need a pipeline stitching three systems together to answer one question.

The graph in between stores context beyond the basic entities, like which amendment changed which clause and what's still standing after it.

[ApertureData @ApertureData]

People type "Scarlet Johanson." A typo-tolerant full-text match on the name finds Scarlett Johansson as the entity, and the knowledge graph traversal can start there: films, co-stars, their other work.

Each query word gets its own max_edits. The search starts with exact matches, allows one more edit at a time up to the ceiling you set, and stops at the first step that returns results. Results are ranked with BM25.

The constraint, on a property with a fulltext index:
[{"fulltext": ["$name", "harbr lihgts", "all", 4]}, ">", 0]

Docs:
https://t.co/fpr7ZIAlSC

[Vishakha Gupta-Cledat @vishakha041]

We have a name for the data layer most AI teams end up with: the Frankenstack.

A search engine for text, a vector database for similarity, a knowledge graph for relationships. Pipelines stitch them together so one question can touch all three. The data gets copied between systems and has to stay in sync. The filtering logic ends up in application code, because no single system sees the whole picture.

We built ApertureDB (@ApertureData) so those three live in one engine. When we measured it:

- Vector search runs 2 to 10x faster than popular vector databases
- Property-graph queries run about 30x faster than well-known alternatives
- Teams that consolidate these along with their unstructured data onto ApertureDB see up to 35x overall

The 35x is the one I care about most, because it's what happens when the pipelines between systems go away.

(I won't name the alternatives. You probably have a few of them running right now.)

[Vishakha Gupta-Cledat @vishakha041]

Type "Scarlet Johanson" into a knowledge graph and see where you end up.

The name is the way in. An actor is an entity linked to films, directors and co-stars, and the traversal starts from whatever the lookup returns. Vector search will surface something close. But "Scarlet" is also a Marvel character, so the result can drift to the wrong entity. And if the lookup misses entirely, there's nothing to traverse from.

That's one of the reasons we made text a first-class modality in ApertureDB (@ApertureData). Fuzzy search starts with exact matches. Then it allows one more edit at a time, up to a ceiling you set, and stops at the first step that returns results. Closer spellings win, and the graph walk starts from the right node.

It matters more when an agent is the one searching. Say the query returns 40 films. The agent isn't going to read all 40. With BM25 relevance scores and facets over the results, it can see a clear lead and act on the first result. If the scores are close, it can use counts per genre or release year to add a filter and narrow the query.

Read more here: https://t.co/9mg5DO7cDG

[Vishakha Gupta-Cledat @vishakha041]

"Pull movie clips where Brad Pitt is eating a sandwich."

That was the query I used at @_odsc AI West on Tuesday to explain why AI's data layer needs three things at once. It sounds like a silly request, but answering it takes every piece:

- Multimodal storage, because the answer lives in video clips
- A knowledge graph, to connect a person (Brad Pitt) to the clips he appears in
- Vector search, to find the moments that look like someone eating a sandwich

If those live in three separate systems, you end up building a pipeline just to ask one question.

It was a large room, and we broke for lunch right after. People still came up to say this was the challenge they were facing. They asked how much flexibility they have to plug in their own models, and how we're building memory on top of ApertureDB (@ApertureData). That's Aperture Nexus, and it's open source. A few also told me adding text search was a good move.

(The shuttlecraft keeps earning its place.)

[Vishakha Gupta-Cledat @vishakha041]

Dave Bechberger on why an LLM is like a junior analyst on their first day, every session, and why relevance beats volume.

Watch the full episode of The Cognitive Layer on YouTube:
https://t.co/XgsSTgrJQe

Listen on Spotify:
https://t.co/kfHMwrHERm

[Vishakha Gupta-Cledat @vishakha041]

We built a spaceship, and customers kept asking us for a shuttlecraft.

ApertureDB started at Intel Labs a decade ago as a database for images, video, and the ML pipelines around them. By the time we had a distributed engine with all the enterprise pieces in place, RAG and GraphRAG had moved most of what people store and query to text and documents.

As researchers, that was a little disappointing. Full-text and fuzzy search in particular felt like a step away from being an AI database. Then we looked at why customers wanted them. A lot of the time, the shuttlecraft is how the crew gets to the spaceship.

So text caught up in @ApertureData: text vector search in the UI, SQL workflows, MMR reranking for RAG, and now typo-tolerant full-text search with BM25 ranking, configurable text indexes, and facets and aggregation.

(Yes, I'm a Star Trek fan.)

https://t.co/9mg5DO7cDG

[Vishakha Gupta-Cledat @vishakha041]

We started treating text as a first-class modality in ApertureDB (@ApertureData) last year, because the workload moved. Images and video used to dominate. With RAG and GraphRAG, most of what people store and query now is text and documents.

Three needs kept coming up.

Prefiltering before nearest neighbor search. You want movie posters that look like one you love, but only from films released after 2010 with a particular actor. If you take the 10 nearest posters first and filter afterward, you can end up with two results, or none, because the closest posters belong to other films. Narrow the candidates with text attributes and graph relationships first. Then KNN runs only on records that can actually match.

Knowledge graph lookups. The way into a graph is usually a name someone typed, and people type "Scarlet Johanson." A typo-tolerant text match finds the right entity, so the traversal has somewhere to start.

Agents. An agent can't skim a page of 40 results the way a person does. It needs a confidence score for each match. It also needs counts by genre or release year so it knows which filter to add next.

What shipped: typo-tolerant full-text search with BM25 relevance ranking, configurable text indexes with case-insensitive matching, and facets and aggregation over results. Fuzzy search tries exact matches first. Then it allows one more edit at a time, up to a ceiling you set, and stops at the first step that returns results, so closer matches win.

Teams that would otherwise stitch together a search engine, a vector database and a knowledge graph can do all three in one engine.

More in the blog: https://t.co/9mg5DO7cDG

[Vishakha Gupta-Cledat @vishakha041]

AI’s data layer needs three things at once: vector search for what looks similar, a knowledge graph for how things connect, and multimodal storage for text, documents, images, and video.

The design decisions behind it, at @_odsc AI West. Tue Oct 27, 12:35 PM. Attending? DM me.

[Vishakha Gupta-Cledat @vishakha041]

A customer moved off MongoDB because their embeddings and complex metadata no longer fit in a document.

MongoDB limits how large a single document can be. Once each record carried its embeddings plus rich metadata, they ran into that limit and had to split the data apart. Putting it back together at query time meant joins, and joins in Mongo were slow.

On ApertureDB (@ApertureData) there's no per-record cap on metadata, and embeddings, metadata and relationships live in the same database, so a query doesn't have to reassemble a record before it can answer. In the testimonial on our site, they also said it gave them "the flexibility to move toward GraphRAG."

[Vishakha Gupta-Cledat @vishakha041]

AI teams get about 3 months to prove a project works. Assembling the data for it can take 6 to 12.

Take a retailer. Product images, catalog, inventory and shipping data are each owned by a different team and each sits in a different system. The project spends its window stitching those together, and the returns never show up in time.

We built ApertureDB (@ApertureData) to remove that Frankenstack: one database for vectors, property graph, metadata and files, instead of four stores glued together.

What we've measured:
- Text-based vector search: 2 to 10x faster than popular vector databases
- Property graph: ~30x faster than well-known alternatives
- Up to 35x faster overall once the separate stores are retired

We also just launched full-text and fuzzy search, so there's one less system to bolt on.

[ApertureData @ApertureData]

@pallavi_bhatt28 We have also added the ability to navigate graph on our UI dashboard now. You can not only see the schema but drill into the various data types. More on that coming soon!

[ApertureData @ApertureData]

This collaboration also gave us an opportunity to launch UI support for our text vector search features!

[Vishakha Gupta-Cledat @vishakha041]

Recently, the team at https://t.co/5r2ugYz5gf (Praneel Panchigar, Nisshutosh Sharma, Torlach Rush, and Ankesh Kumar) decided to 𝗺𝗼𝘃𝗲 𝗳𝗿𝗼𝗺 𝗠𝗼𝗻𝗴𝗼𝗗𝗕 𝘁𝗼 𝗔𝗽𝗲𝗿𝘁𝘂𝗿𝗲𝗗𝗕 for their text‑ and metadata‑heavy workloads and replaced a vector‑only setup that struggled under real retrieval patterns.

@isonic_ai 𝘣𝘶𝘪𝘭𝘥𝘴 𝘈𝘐 𝘢𝘴𝘴𝘪𝘴𝘵𝘢𝘯𝘵𝘴 𝘵𝘩𝘢𝘵 𝘵𝘶𝘳𝘯 𝘢 𝘤𝘳𝘦𝘢𝘵𝘰𝘳’𝘴 𝘦𝘯𝘵𝘪𝘳𝘦 𝘤𝘰𝘯𝘵𝘦𝘯𝘵 𝘭𝘪𝘣𝘳𝘢𝘳𝘺 𝘪𝘯𝘵𝘰 𝘢𝘯 𝘪𝘯𝘵𝘦𝘳𝘢𝘤𝘵𝘪𝘷𝘦 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦 𝘵𝘩𝘢𝘵 𝘢𝘯𝘴𝘸𝘦𝘳𝘴 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯𝘴, 𝘴𝘶𝘳𝘧𝘢𝘤𝘦𝘴 𝘵𝘩𝘦 𝘳𝘪𝘨𝘩𝘵 𝘮𝘢𝘵𝘦𝘳𝘪𝘢𝘭, 𝘢𝘯𝘥 𝘩𝘦𝘭𝘱𝘴 𝘤𝘳𝘦𝘢𝘵𝘰𝘳𝘴 𝘮𝘰𝘯𝘦𝘵𝘪𝘻𝘦 𝘮𝘰𝘳𝘦 𝘦𝘧𝘧𝘦𝘤𝘵𝘪𝘷𝘦𝘭𝘺.

What stood out wasn’t just that they switched to ApertureDB, 𝗶𝘁 𝘄𝗮𝘀 𝙬𝙝𝙮.

In their benchmarks, ApertureDB 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝘁𝗹𝘆 𝗼𝘂𝘁𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗲𝗱 𝗖𝗵𝗿𝗼𝗺𝗮 on retrieval, but performance was only part of the story. They needed reliability under load, richer metadata models without arbitrary limits, and a clean path toward graph‑based retrieval as their product evolves. And they valued choosing infrastructure that won’t constrain them if they needed to introduce other modalities.

This journey mirrors what we see across teams building real production systems. 𝗩𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 𝗶𝘀 𝗮 𝗽𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗯𝗹𝗼𝗰𝗸, 𝗯𝘂𝘁 𝘃𝗲𝗿𝘆 𝗳𝗲𝘄 𝘄𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀 𝘀𝘁𝗮𝘆 𝘃𝗲𝗰𝘁𝗼𝗿‐𝗼𝗻𝗹𝘆 𝗳𝗼𝗿 𝗹𝗼𝗻𝗴. As products mature, teams start needing:
• metadata that can grow without ceilings
• relationship‑aware retrieval
• graph‑structured context
• and the option to go multimodal when the time is right

It’s encouraging to see teams make that transition intentionally, not because a tool is trendy, but because their workloads demand more flexibility, reliability, and room to grow.

Curious how others are thinking about this shift as their retrieval and data layers mature.
@ApertureData

[Sonam Gupta @Coffee_and_NLP]

What does “memory” actually mean to different AI builders? This seemingly basic question came up during a discussion (and a penguin) at yesterday’s Agentic Memory Meetup, and it was interesting to hear how differently people think about it depending on what they’re building.

For some, memory is about retaining conversations across sessions. For others, it’s about retrieving knowledge, maintaining context, or ensuring an agent doesn’t keep making the same mistakes.

My talk, “From Benchmark Data to Grounded Answers with Aperture Nexus,” explored a slightly different problem: how do you build an AI assistant that remembers internal product knowledge without treating outdated information as current fact?

I walked through a sales enablement assistant I built using Aperture Nexus and ApertureDB, where historical benchmark reports become retrievable context, while live Telnyx data provides up-to-date product information. I also shared some of the architectural decisions, things that didn’t work initially, and a live demo of the assistant.

One thing I find interesting about agent memory is that remembering more isn’t necessarily the goal. Knowing what to retrieve, what to trust, and when to fetch fresh information is just as important.

Huge thanks to @vishakha041 from @ApertureData and @OutcastVC for inviting me and bringing together builders working on different aspects of AI memory.

Curious how others are approaching this. What does memory mean in the context of the AI applications you’re building?

[Sonam Gupta @Coffee_and_NLP]

Event starting soon with penguins and everything at @ApertureData and @OutcastVC .. beyond penguins we will chat agentic memory too

[Sonam Gupta @Coffee_and_NLP]

I’m speaking tomorrow at the Agentic Memory Meetup in San Francisco.

My talk, “From Benchmark Data to Grounded Answers with Aperture Nexus,” covers how I built an internal sales enablement assistant that turns benchmark reports and product knowledge into useful, source-grounded answers.

I’ll walk through:
- How Aperture Nexus and ApertureDB make benchmark context retrievable
- How Telnyx provides the live model catalog and Inference API used to generate the final answers
- Why changing product facts need a live source of truth
- The architecture decisions that reduced hallucinations
- What we learned when model reasoning accidentally reached the UIA live demo of the assistant

If you are working on agent memory, RAG, grounded generation, or internal AI tools, come say hello!
📍 San Francisco
📅 Tomorrow, October 13
RSVP -> https://t.co/LW1qiemZlF

P.S.: Thank you @ApertureData and @OutcastVC for organizing this event.