By Pull your chair a little closer. The fire is still warm.
Before Stack Overflow. Before Reddit threads. Before Discord servers full of Oracle developers trading solutions at midnight. There was a different kind of help. Slower. More deliberate. The kind you got by posting to a mailing list and waiting, sometimes for days, for someone who actually knew the answer.
And then, in the late 1990s, one man decided to fix that.
He did not build a community platform. He did not launch a forum where thousands of people could share the load. He opened a website and said, essentially: ask me anything about Oracle Database. I will answer it personally.
For nearly two decades, he kept that promise.
The Oracle World Before AskTom
In 1999, if you had a serious Oracle Database question, your options were limited.
You could post to a USENET newsgroup and hope someone with the right experience happened to be reading that day. You could dig through the Oracle documentation, which was accurate but dense, and rarely gave you the direct answer to the specific problem in front of you. You could call Oracle Support, which cost money and took time. Or you could ask a colleague and hope your team had someone senior enough to know.
The gap between “I have a question” and “I have an answer I can trust” was wide.
Tom Kyte understood that gap better than most. He had joined Oracle Corporation in 1993 as a consultant, and the Oracle questions never stopped coming. Customers had them. Developers had them. Partners had them. The same questions, sometimes. Different contexts, always.
He had been answering them for years. He decided to start doing it in public.
The Website That Changed Everything
AskTom launched in 1999 at asktom.oracle.com.
The concept was simpler than it sounds dangerous. You submitted a question. Tom Kyte, Distinguished Product Manager at Oracle, read it and wrote back. Not a support ticket routed to a team. Not an AI-generated response. Tom himself, typing an answer.
He had one rule from the start. If you asked a question without a test case, without a reproducible example showing what you were working with and what was going wrong, he would ask for one before engaging. No vague descriptions. No “I have a performance problem, what should I do?” Show him the schema. Show him the query. Show him the data. Then he would help.
That rule shaped how an entire generation of Oracle developers learned to think.
The volume was not small. Over the lifespan of AskTom, Tom Kyte personally answered more than 65,000 questions. That number is not a typo. Sixty-five thousand questions. Each one read, considered, tested where needed, and answered in writing. The site eventually accumulated millions of page views from Oracle developers around the world who discovered that the best way to find the answer to a difficult database question was to search AskTom first.
It Depends
If you spent any time on AskTom, you saw two words more than any others.
It depends.
Tom Kyte said it constantly. Developers mocked it affectionately. They put it on t-shirts. They used it as a punchline in conference talks. And underneath the joke was something real: he said it because it was almost always true.
Does a full table scan hurt performance? It depends. What is the table size? What are you selecting? What does your storage look like? What else is running? Should you use an index here? It depends. On the selectivity of the column. On how many rows you are touching. On whether the optimizer can use it efficiently.
The Oracle world is full of confident declarations that fall apart under examination. “Never use SELECT *.” “Always use bind variables.” “Partitioning will fix it.” Tom Kyte spent twenty years gently dismantling the ones that deserved dismantling, and it always came back to the same answer: it depends, and here is what to measure to find out.
That epistemology stuck. The developers who grew up reading AskTom came out the other side asking different questions. Not “which is faster?” but “faster under what conditions?” Not “is this bad practice?” but “in what context does it become a problem?”
If you want to understand why the best Oracle developers think the way they do, that is a large part of the answer.
The Book That Sat on Every Desk
While AskTom was running, Tom Kyte also wrote.
Expert Oracle Database Architecture went through multiple editions. It was not the kind of book you bought and placed on a shelf to look credible. It was the kind of book that fell open to the chapter on undo and redo because you had read it four times and the spine had given up. Developers who were starting their Oracle careers in the 2000s and 2010s often describe it the same way: the book that turned them from someone who used Oracle into someone who understood it.
The book and the website fed each other. AskTom gave him an endless source of real-world problems that the documentation had not covered. The book gave readers the conceptual framework to understand the answers they were finding on the site. Together they did something that formal Oracle training rarely managed: they explained not just what to do but why, traced back to how the database engine actually worked.
The Fire He Left Behind
Tom Kyte retired from Oracle around 2018. He stepped back from AskTom and from the public Oracle world that had built itself around his name.
AskTom still exists. It is maintained now by the Oracle Database and APEX teams, with a broader community of experts contributing answers. The archive of his original responses is still there, still searchable, still cited in Oracle forums and Stack Overflow threads and Slack channels where developers are trying to figure out why their query plan changed.
The Oracle ACE community that carries this kind of institutional memory forward is, in part, a direct continuation of what AskTom established. The idea that the right way to be useful is to share what you actually know, in public, for free, in writing, and to insist on precision over speed.
That is still the best model. It is the one this blog tries to follow.
Sixty-five thousand questions. One man. Nearly two decades.
He did not do it to build a brand or grow an audience. He did it because the questions deserved answers, and he was the person who could give them. That is the whole story, and it is a good one.
The fire is still going. Same time next month, last Friday of August.
