Bedrock Knowledge Bases vs. DNotifier RAG

Part of a series on running AI workflows across model providers — this one is about where your retrieval-augmented-generation pipeline should actually live when you're already touching AWS.

Both Bedrock and DNotifier offer a managed way to ground model responses in your own documents instead of the model's general training knowledge — but they connect to different sources, price differently, and fit different points in an architecture.

What Bedrock Knowledge Bases handles

Bedrock's Knowledge Bases is a fully managed RAG pipeline that connects directly to Amazon S3, Microsoft SharePoint, Confluence, Google Drive, Microsoft OneDrive, and web crawlers for public or internal pages. It automatically determines the right parsing strategy for each data type and connector, preserving metadata, images, and multimodal content without manual configuration, and handles chunking and vector storage without you standing up a separate vector database. Its more advanced "agentic retrieval" mode understands a user's intent, identifies the most relevant data sources across several possible connectors, and iterates across multiple retrieval steps for complex queries — priced per query rather than by token, which gives more predictable cost for that specific feature.

Bedrock's Knowledge Bases connects to where enterprise documents already live — S3, SharePoint, Confluence — without a separate ingestion pipeline to build.

What DNotifier's built-in semantic search handles instead

DNotifier's approach folds RAG directly into the same runtime as everything else: upload documents to a knowledge base, and semantic search runs over them without managing a vector database, an embedding pipeline, or separate infrastructure — the same way session memory and workflow orchestration are unified rather than assembled from separate services. It's a narrower integration surface than Bedrock's — DNotifier doesn't natively connect to SharePoint or Confluence the way Bedrock does — in exchange for staying inside one platform alongside the orchestration and realtime layers a workflow already uses.

DNotifier's RAG lives inside the same runtime as orchestration — one less system to wire together, at the cost of Bedrock's broader native connector list.

The actual decision

If your source documents already live natively in SharePoint, Confluence, or a mix of enterprise systems Bedrock connects to directly, and you're already inside an AWS account for other reasons, Knowledge Bases' native connectors save real integration work. If your documents can be centralized into a knowledge base you control directly — uploaded, synced, or exported from wherever they originate — and the rest of your agent logic is already running through DNotifier's orchestration layer, keeping retrieval in the same runtime avoids a second system to monitor, secure, and keep in sync with the rest of the workflow.

A real use case: picking based on where the documents already lived

An internal-tools team building a policy-lookup assistant had their source documents split across two places: a large, actively maintained Confluence space that the whole company edited daily, and a smaller, more static knowledge base of finalized compliance PDFs that rarely changed. Rather than force both into one system, they used Bedrock Knowledge Bases' native Confluence connector for the actively changing content — so updates in Confluence flowed through automatically — and loaded the static compliance PDFs directly into DNotifier's knowledge base, since that set didn't need a live connector and benefited more from sitting alongside the DNotifier workflow that handled the actual approval routing for policy questions. Both retrieval pipelines fed into the same agent's decision-making, chosen based on where each document set actually lived and how often it changed.

Frequently asked questions

Can I use both Bedrock Knowledge Bases and DNotifier's semantic search in the same application?

Yes — a workflow can query both and combine the results, choosing per-document-set which retrieval pipeline makes sense, as in the use case above.

Does DNotifier's knowledge base support the same file types as Bedrock's?

Both support common document formats; Bedrock's advantage is native, automatic connectors to specific enterprise platforms (SharePoint, Confluence, Drive) rather than raw file-type support.

Is agentic retrieval pricing cheaper than token-based RAG pricing?

It depends on query volume and complexity — per-query pricing gives predictability rather than a guaranteed discount, since a single complex agentic-retrieval query can involve several underlying retrieval steps.

Do I need a vector database for either option?

No — both Bedrock Knowledge Bases and DNotifier's built-in semantic search manage vector storage internally, which is the core convenience both are selling.

The Bottom Line

Next in this series: the closing piece — why model flexibility matters even for a team that's fully committed to Bedrock today, and how to avoid rebuilding everything if that changes.

Read part ten: Avoiding Lock-In: Bedrock and Beyond. Explore dnotifier.com.