I started looking at RawTree because I kept seeing the same problem in modern software projects: the data changes before anyone has had time to design the perfect system for it.
An event gets a new field. A webhook starts sending a different object. Logs become more detailed. An AI agent begins producing traces, tool calls, retries, and error information that nobody expected when the first version was built.
At that point, a lot of database work becomes guesswork. You either stop and redesign things every time the data changes, or you throw everything into a generic JSON field and hope it will be easy to analyse later.
Neither option feels great. That is what made RawTree interesting to me. I wanted to understand whether its documented approach could make this kind of changing data easier to work with, rather than treating “schema-free” as just another product phrase.
I have not run a large production workload on it, so I am not going to pretend I have benchmarked it myself. This is based on reading the official documentation, looking at the product examples, and thinking through where it could fit in a real stack.
From that review, the strongest point for me is the way RawTree is designed for data that is still changing.
The Database Problem I Kept Coming Back To
Traditional database design makes a lot of sense when you know what you are building. If the data is stable, you can define the tables, choose the important indexes, create reporting views, and set up a pipeline that does the same thing every day.
That kind of planning is useful, but not every workload is stable anymore. Teams collect application events, customer activity, logs, security signals, product analytics, traces, metrics, and AI-related data.
These sources do not always arrive in the same shape, and they can change as the product changes.
AI agents make this even more obvious. A single agent run can include:
- A Prompt.
- A Model Name.
- A Tool Call.
- A Retrieved Result.
- A Response Time.
- A Retry.
- An Error Object.
- Extra Information From The Environment.
The next run may have different fields. You can plan for some of this, but you cannot realistically predict every field that might become useful later. That is the situation RawTree is built around.
So, What Does RawTree Actually Do?
RawTree is an analytical database for unstructured and changing data. You can send events, files, URLs, and telemetry into it, then query the data with SQL.
The idea is that you can start sending information without having to finish a complete schema first. Tables can be created when data is inserted, and the structure can evolve as new data arrives. The basic workflow is simple:
- Send The Data In Its Current Form.
- Query It With SQL.
- See Which Fields And Questions Matter.
- Add More Structure When It Becomes Useful.
Why The SQL Part Matters
The flexible ingestion would not be very helpful if the only way to use the data was to read raw JSON manually. RawTree keeps SQL as the main way to query the information, so you can filter, group, sort, join, and aggregate data instead of treating every record as an isolated object.
For example, if I was collecting information from an AI support agent, I could start asking questions like:
- Which Tools Are Being Used Most Often?
- Which Runs Are Taking The Longest?
- Which Errors Started After A New Release?
- Which Workflows Are Retrying The Most?
- Which Fields Appear Often Enough To Deserve A More Stable Model?
The useful thing is that I can ask those questions while the data model is still developing. In a more rigid setup, I might have to decide the final table structure first.
With RawTree, the first stage can be more exploratory. I can learn what the data is telling me before making every part of the model permanent.
The way I think about it is not “No structure ever.” It is “Do not force all the structure on day one.”
Where AI Agents Fit Into This
RawTree seems like a natural fit for teams building with AI agents. Agents generate a lot of information that can be useful later, including traces, tool calls, logs, intermediate steps, errors, evaluation results, and timing data.
A lot of that information is difficult to model perfectly in advance because the agent workflow is still changing. RawTree’s flexible approach seems well suited to that stage of development.
RawTree provides several ways to work with the database, including an API, CLI, SDKs, MCP, and the platform interface. That gives different types of users a practical way to work with the same system.
A developer might use the CLI, an application might send data through the API, an agent might work through MCP, and a human might inspect what happened in the platform.
I also noticed that RawTree puts limits and permissions at the database level, which is useful when teams want agents to work with clear boundaries.
The official material describes security policies for controlling what agents and applications can access, as well as resource policies for controlling how much infrastructure they can use.
I would still want to test those controls myself before relying on them in a sensitive environment. The overall direction is sensible: the agent can work quickly, while the person responsible for the system keeps control of the boundaries.
It Is Not Only For AI Data
The AI angle is probably what first makes RawTree stand out, but the use case is broader than that. RawTree also supports observability workflows.
Its documentation covers OpenTelemetry ingestion for traces, logs, and metrics. It also documents Prometheus-compatible endpoints for writing and querying metrics. That could be useful for teams that do not want to replace every collector or monitoring tool they already use.
For example, a team might want to compare:
- Application Latency With Agent Tool Calls.
- Error Rates With A Specific Deployment.
- Customer Activity With Infrastructure Events.
- Model Versions With Response Quality.
- Request Volume With Resource Usage.
Those pieces often live in separate systems. When they need to be compared, someone has to move between tools or build a separate correlation layer.
The appeal of RawTree is that these different signals can live in one analytical system and be queried with SQL. That creates a useful way to bring telemetry and other changing events together.
I would not call it a complete observability replacement based only on the documentation. The right fit would depend on the dashboards, alerts, retention, integrations, and operational details a team actually needs.
What I Noticed About The Integration Approach
RawTree also has Apps for certain existing workflows. The official documentation describes integrations around OpenTelemetry, Prometheus, Splunk-compatible ingestion, and DataHub metadata publishing.
I like the idea behind this because most teams do not want to throw away tools that already work. They want to add a new capability without creating another isolated data store.
Keeping a familiar ingestion method while making the result available through SQL is a practical approach. It means teams can explore RawTree without automatically replacing every part of a workflow that already works.
I would still check permissions, limits, failure behaviour, and exactly what data is copied or exposed for each integration. The overall approach is easier to imagine than replacing an entire monitoring or data catalogue workflow just to try a new database.
What About Performance?
This is the part I would look at most carefully. RawTree describes itself as adapting to workloads based on real query access patterns.
The official material says that optimisation follows how clients actually query the data, rather than requiring every index or projection to be planned manually at the beginning. That sounds useful because teams often guess wrong about which fields will matter most.
A field that looks important during planning may barely be queried later. Another field that seemed unimportant may become central once users start working with the product.
I like the principle, but I would still test the exact workload before making a performance decision. I would try different payload sizes, changing fields, concurrent queries, large imports, and repeated analytical queries.
I would also want to see what happens when the workload changes again. The official examples explain the product direction, while testing with real data would show how that direction fits a specific project.
Cloud Or Your Own Infrastructure
RawTree provides a hosted cloud option, and its official materials also describe running it on customer-controlled infrastructure and storage. That can matter when data residency, privacy, regulation, or transfer costs are important.
Keeping data closer to the systems that generate it can make an architecture simpler. It can also reduce the amount of telemetry or AI-generated data that needs to move between environments.
I would still separate the deployment choice from the security decision. Running something in your own cloud does not automatically make it secure or compliant, so I would review access control, encryption, retention, backups, audit logs, and who is responsible for operating the system.
The useful thing is that RawTree gives teams more than one option instead of forcing every workload into exactly the same deployment model.
What I Would Test Before Choosing It
If I were evaluating RawTree for a real project, I would start with a small but realistic sample of the data I expect to collect. I would test:
- Ingestion When New Fields Appear.
- Queries Across Different Payload Shapes.
- Large Imports And Storage Growth.
- Concurrent Queries.
- Agent Permissions.
- Resource Limits.
- OpenTelemetry And Prometheus Workflows.
- Retention And Backup Behaviour.
- Cloud Versus Customer-Controlled Deployment.
- Pricing For The Actual Workload.
I would also check what happens when an exploratory dataset becomes important enough to support regular reporting. That seems like an important part of the evaluation.
The best case is not that the data stays unstructured forever. The best case is that the team can begin quickly, learn from real usage, and introduce more stable structure when it is justified.
My Bottom Line
The thing I find most interesting about RawTree is not simply that it accepts changing data. It is that it seems designed around the reality that teams often discover their data model while building the product.
That is happening with application events, telemetry, agent runs, and many other modern workloads. The information is being generated before the team knows exactly which questions it will want to ask.
RawTree offers a way to start with that raw information, query it with SQL, and let actual usage influence what happens next. That gives teams room to explore before they commit to a final data model.
I would still test performance, permissions, costs, retention, and deployment with a real workload before putting important data there. Even so, I can see why RawTree would appeal to teams building AI agents, collecting observability data, or dealing with event payloads that change every few weeks.
For me, RawTree makes sense as a database for the stage between “We have no idea what this data will look like” and “We now understand the workload well enough to optimise it properly.”
That is a useful stage, and many teams spend more time in it than they would like to admit.
Sources
This article is based on those official RawTree sources. It does not claim independent benchmarks or production results.