I did not come to RawTree because I was looking for another database to add to a list. I started looking at it because modern projects keep producing data that is difficult to predict in advance.
That is especially true when a product is collecting events, telemetry, logs, or information from AI workflows. The useful fields are not always obvious on the first day, and the shape of the data can change while the product is still being built.
After reading RawTree’s official material, I can see why this approach is getting attention. It is built around the idea that teams should be able to work with changing data first and add more structure as they learn what matters.
I have not run a large production workload on RawTree, so this is not a personal benchmark or a claim about results I measured myself. It is my honest take after reading the official website, documentation, and product examples.
From that review, the strongest point for me is the way RawTree is designed for data that is still changing.
The Question I Would Start With
Before choosing any data platform, I would ask a simple question: do we already know what our data will look like six months from now?
For a stable system, the answer may be close to yes. A company may already know which records it needs, which reports it will run, and which relationships need to be kept consistent. Traditional modelling works very well in that situation.
Other projects are different. An event can gain new fields after a product release. An application can start collecting more detailed telemetry. An AI agent can introduce new tools, intermediate steps, and evaluation signals as the workflow develops.
That is where RawTree’s positioning makes sense to me. It is designed for analytical work with data that is unstructured or still evolving, instead of assuming that every field has been planned perfectly from the beginning.
What Made RawTree Stand Out To Me
The most interesting part is the combination of flexible data ingestion and SQL analysis. RawTree’s documentation explains that teams can send in events, files, URLs, and telemetry, then query that information with SQL.
That combination matters. Flexible ingestion on its own could leave a team with a large collection of objects that is difficult to use. SQL gives the data a familiar way to be explored, compared, filtered, grouped, and aggregated.
I also like that the workflow does not require the final data model to be decided immediately. The process can look more like this:
- Start With The Data You Actually Have.
- Use SQL To Find Useful Patterns.
- Notice Which Fields Keep Appearing.
- Add More Structure When The Workload Justifies It.
That feels practical for a team that is still learning. It leaves room for exploration without suggesting that structure is unnecessary forever.
The AI Connection Is Easy To Understand
RawTree’s AI connection is one of the easier parts of the product story to understand. AI agents create many kinds of information during a single run, and the exact shape of that information can change as the agent changes.
A team may want to keep track of prompts, model names, tool calls, retrieved information, timing, retries, errors, evaluation data, or details from the environment. Some of those fields may be obvious from the beginning. Others may only become useful after people review real runs.
This is where a flexible analytical system can be helpful. The team can collect the broader picture first, then use SQL to understand which questions are worth asking regularly.
RawTree also documents several ways to work with the system, including an API, CLI, SDKs, MCP, and its platform interface. I see that as a useful combination because developers, applications, agents, and human reviewers may all need different entry points.
A Broader Use Case Than AI
I would not limit RawTree to agent data. Its official documentation also covers observability workflows, including OpenTelemetry ingestion for traces, logs, and metrics, as well as Prometheus-compatible endpoints for writing and querying metrics.
That opens up a wider set of questions. A team might want to look at application latency next to infrastructure events, compare error patterns with deployment changes, or connect request volume with resource usage.
Those signals often begin in separate systems. Bringing them into one analytical environment could make cross-system analysis easier, especially when the data is changing and the team is still deciding which relationships deserve a permanent model.
I would still evaluate the surrounding observability features separately. Dashboards, alerts, retention, integrations, and operational ownership are all important. The official documentation supports the data-ingestion and SQL use case; it does not remove the need to check the complete workflow.
How I Would Try It
If I were starting a real evaluation, I would keep the first test focused. I would not begin with every possible source or the largest dataset available. I would choose one changing workload that represents the problem RawTree is meant to solve.
First, I Would Pick A Real Dataset
That could be application events, agent runs, traces, or another stream where new fields are likely to appear. The goal would be to see whether the data can be collected in its current form without delaying the project for a complete schema design.
Next, I Would Ask Real Questions
I would use the questions the team already needs to answer, rather than creating an artificial benchmark. For example:
- Which Fields Change Most Often?
- Which Queries Matter Every Week?
- Which Events Need To Be Joined?
- Which Workflows Produce The Most Retries?
- Which Signals Should Become Part Of A Stable Model?
This would show whether the flexible starting point is useful beyond the initial ingestion step.
Finally, I Would Check The Operating Details
The official material describes security policies for controlling access and resource policies for controlling infrastructure usage. Those capabilities are important, especially when an AI agent or application is allowed to interact with a database.
I would test those policies with the actual roles, data, limits, and workflows the project needs. I would also review retention, backups, permissions, deployment options, and the cost of the expected workload before making a long-term decision.
What I Like About The Deployment Choice
RawTree provides a hosted cloud option, while its official materials also describe running it on customer-controlled infrastructure and storage. I think that flexibility is valuable because teams do not all have the same privacy, residency, regulation, or operating requirements.
A hosted option can make it easier to get started. Customer-controlled infrastructure can be useful when a team needs more control over where data is stored and how it moves between systems.
The important point is that deployment flexibility should still be paired with a proper security review. The option to control infrastructure is useful, but it does not replace access controls, encryption, retention policies, backups, or clear ownership.
The Part I Would Watch Closely
RawTree describes an optimisation approach that follows real query access patterns. I find that idea appealing because it recognises that teams often do not know which fields will matter most until people start using the data.
A field that seems central during planning may barely be queried in practice. Another field may become important only after a new workflow appears. Letting actual usage inform optimisation is a sensible direction for changing workloads.
I would still test it with realistic data before making a performance claim. My test would include different payload sizes, changing fields, concurrent queries, imports, and repeated analytical queries.
That is not a criticism of RawTree. It is simply the kind of check I would make with any data platform that is going to support important work.
Where I Landed On It
What I like about RawTree is that it seems to match the way many modern products are actually built. The data starts arriving before the team has finished deciding what the final model should be.
RawTree gives that early information a place to go, keeps SQL at the centre of analysis, and leaves room for the structure to become more deliberate over time. For AI agents, observability data, telemetry, and changing event payloads, that is a clear and useful idea.
I would still evaluate the details with a real workload, especially permissions, performance, retention, pricing, integrations, and deployment. But based on the official information, RawTree looks like a strong option for teams that want to learn from their data before locking every decision into a fixed schema.
For me, that is the main value: RawTree can support the messy learning stage between collecting data for the first time and understanding the workload well enough to optimise it confidently.