Why Your Next AI Project Doesn’t Need a Separate Vector Database

Your AI strategy doesn’t need a new database. It needs the one you already trust to do more. Meet the latest version of HCL Informix®, the enterprise database that’s now AI-ready.

Say your team wants to add a support chatbot that finds similar past tickets automatically.

A few weeks in, you hit the usual wall. To search by meaning instead of exact words, you need a vector database. That means a new vendor, a new pipeline to copy your data over to, and a new security review before it can touch real customer data.

The chatbot didn’t get harder to build. Everything around it did.

This post explains why you probably don’t need that extra system and shows the actual SQL for performing semantic search through the database you already run. You’ll also see how vector search can be used alongside your existing business data without requiring application teams to independently deploy and manage a separate vector database service.

The Fastest Way to Add AI isn’t a New Database

The quickest path to AI could be teaching the database you have a new trick.

Let’s say you run a production HCL Informix database for orders, billings, and claims business processes every day. A product team wants a chatbot with a search feature that uses AI, and the team wants it soon. You’re fine with that. What worries you is what a whole new database adds to your plate, including one more system to patch, one more vendor to get security sign-off on, and one more pipeline that can quietly break.

Maybe you’ve already looked at Pinecone, Weaviate, or pgvector. This is the case for checking whether you actually need to add a new database:

Quick Basics: What’s a “Vector,” and Why Does Search Need One?

A vector is a list of numbers that stands in for the meaning of a piece of text. Two sentences that mean the same thing end up as two lists of numbers that are close together, even if they don’t share a single word.

“How do I reset my password?” and “I forgot my login credentials” mean the same thing, so their vectors sit close together. Searching by that closeness instead of matching exact words is what people mean by “vector search.” It’s the trick behind every chatbot that seems to “understand” what you’re asking.

Why a Separate Vector Database Costs More than the Initial Cost

The usual setup sounds simple but adds up fast:

Stand up a separate vector database
Pay for it and run it as its own system
Build a pipeline that copies your data into it and keeps both sides in sync
Give it its own security review, backups, and disaster recovery plan

That third point is where the real cost hides. A 2026 study of enterprise data pipelines found that big companies run several hundred of them on average and those pipelines break several times a month, each one taking hours to fix. That’s not on any vector database’s pricing page. It shows up later, in your on-call rotation.

HCL Informix skips most of that list. Vector search is integrated through HCL Informix VectorBlade, so application teams do not need to deploy and manage a separate vector database service with its own operational lifecycle. Keeping vector data synchronized with your Informix data can be initiated with a stored procedure call from inside the database rather than relying on a separate application-side synchronization pipeline.

Why Integrated Vector Search Simplifies the Architecture

With VectorBlade, you can use vector search alongside business attributes such as customer tier, region, or other metadata associated with the vector search workflow:

“Find tickets like this one, but only from Platinum customers in EMEA.”

A separately managed vector database often requires applications to copy and synchronize the metadata needed for filtering. With HCL Informix and VectorBlade, vector search is integrated into the Informix workflow alongside the business data your applications already manage, reducing the need for additional application-side integration and synchronization logic.

Let’s start with a simple use case.

Enabled by the VectorBlade solution, we’ll create a VectorBlade-managed vector table that can be used to store vectors and perform “nearest neighbor” searches on them:

• This VectorBlade-managed vector table has three columns of the following types: bigint, embedding, lvarchar.
• The bigint column stores vector IDs. These must be unique numbers.
• The embedding column can store vectors with any number of dimensions, but that number must be specified at table creation time.
• The lvarchar column is for storing textual metadata. This metadata can be anything you like and can be useful for filtering.

Assuming your OpenAI key is set properly and you are able to successfully execute the lvector_embed() routine, the following example will be of interest:

Example:

-- Create a new traditional table
database examples;
create table ifx_sample_tab3 (
ident bigint,
embedding_data lvector_embedding,
text_data lvarchar,
metadata lvarchar,
primary key (ident)
);

-- Generate some real embeddings and insert them into our table
insert into ifx_sample_tab3 values (
1,
lvector_embed('This text is about squirrels'),
'This text is about squirrels',
'This metadata will not be used in this example'
);

insert into ifx_sample_tab3 values (
2,
lvector_embed('This text is about car racing'),
'This text is about car racing',
'This metadata will not be used in this example'
);




insert into ifx_sample_tab3 values (
3,
lvector_embed('This text is about architecture'),
'This text is about architecture',
'This metadata will not be used in this example'
);

insert into ifx_sample_tab3 values (
4,
lvector_embed('This text is about wrestling'),
'This text is about wrestling',
'This metadata will not be used in this example'
);

insert into ifx_sample_tab3 values (
5,
lvector_embed('This text is about sound'),
'This text is about sound',
'This metadata will not be used in this example'
);

Say we want to find the text most relevant to the question, “Tell me about building design.” First, we create a VectorBlade-managed vector table that we can use to perform this search. In this example, the vectors have 1536 dimensions, matching the embedding model used for the example:

EXECUTE PROCEDURE lvector_create_table('sample_tab3', 1536);

Now we synchronize this VectorBlade-managed vector table with our traditional table:

EXECUTE PROCEDURE lvector_bulk_sync('ifx_sample_tab3', 'sample_tab3', 'ident', 'embedding_data');

Now we can perform a true vector search:

Search 1:

SELECT text_data FROM ifx_sample_tab3 WHERE ident IN (SELECT * FROM TABLE(lvector_id_search('sample_tab3', lvector_embed('Tell me about building design'), 1)));

You should see that the results of this vector search are:

text_data This text is about architecture

Search 2:

SELECT text_data FROM ifx_sample_tab3 WHERE ident IN (SELECT * FROM TABLE(lvector_id_search('sample_tab3', lvector_embed('Tell me about cute rodents'), 1)));

Expected results:

text_data This text is about squirrels

Search 3:

SELECT text_data FROM ifx_sample_tab3 WHERE ident IN (SELECT * FROM TABLE(lvector_id_search('sample_tab3', lvector_embed('Tell me about sports'), 2)));

Expected results:

text_data This text is about car racing

text_data This text is about wrestling

No separate vector database service for the application team to deploy. No extra application-side query to stitch together two separately managed systems. The vector search remains part of the Informix workflow.

How to Check That Everything is Actually Working

Before you call this done, check these four things:

1. Do the results make sense? Run 20 real questions through lvector_search() and see if the top answers look right to a person. If fewer than eight out of 10 look right, adjust the setup before you ship it.
2. Does the filter actually work? Run the query and check that every result matches the filter. If it ever returns something outside the filter, that’s a bug, not a quirk.
3. Is it fast enough under real load? Test it with many searches happening at once, not just one. If it’s much slower than your normal queries, that’s a sizing issue, not a reason to add a second database.
4. Does it respect who can see what? Make sure someone who can’t normally see a record can’t find it through search either.

If all four check out, you know it works, and it’s not just that the demo worked.

You might still have the question, “But isn’t a dedicated vector database better?” Here’s the reality:

At a huge scale of billions of items, like a public web search, a purpose-built vector database can be faster. That’s true, not just marketing.

But most companies aren’t doing that. They’re searching their own data, such as tens of thousands to a few million records, where staying accurate matters more than shaving off a few milliseconds. For that much more common case, skipping the extra system isn’t a compromise. It’s simpler, and it has fewer places to break.

One Database, Five Kinds of Data

Vector search is the newest addition, not the first. HCL Informix has handled several kinds of data in one place for years:

The Key Takeaways

Most AI features need to search across data you already have, which does not necessarily require deploying and managing a separate vector database service.

VectorBlade lets you use semantic search alongside existing business data while reducing the need for separate application-side data copies, synchronization pipelines, and integration logic.

Check the AI-enabled database the way you’d check anything: does it give good answers, does the filter work, is it fast enough, and does it respect access rules.

You don’t need to add and manage another database service just to build AI search features. With HCL Informix and VectorBlade, you can extend the database environment you already use with integrated vector search capabilities.

Bring AI to the data you already trust — not the other way around. Get HCL Informix® 15 with VectorBlade and benefit from integrated vector search, semantic query capabilities, and support for RAG workflows through the database environment you already run. HCL Informix 15

Informix is a trademark of IBM Corporation in at least one jurisdiction and is used under license.

About Author

About Gaurav Kumar

Gaurav Kumar is Actian’s Senior Informix Technical Support Engineer with over 15 years of experience helping enterprise customers solve complex database challenges. He specializes in HCL Informix® with experience resolving downstream incidents and expertise in performance tuning, high availability, replication, security, and AI-powered database capabilities. He enjoys sharing technical knowledge through blogs, webinars, and demo videos, making it easier for customers to adopt new technologies.