DBMS Interview - February 1994
Tackling database applications that manage images, documents, and other complex data types will take a new kind of DBMS, says Dr. Michael R. Stonebraker. And he should know. As professor of Elctrical Engineering and Computer Sciences at the University of California, Berkeley, he led the Ingres RDBMS project, and in 1980 co-founded Relational Technology, Inc. (later renamed Ingres Corp., then acquired by The Ask Group) to commercialize the work. He later headed Berkeley's Postgres project, and in 1992 cofounded Montage Software, where today he serves as a director and chief technology officer.
The new kind of DBMS to which Stonebraker refers is his own Montage Server -- what he calls an Object-Relational database or ORDBMS. The Montage Server, which is based on the Postgres code, provides all the services of a traditional relational DBMS, with key extensions such as user-defined data types and object definition. These two features in particular allow database designers to model highly complex objects, yet hide this complexity from users and application developers.
To complement the new features of its server, Montage Software offers Foundation, Text, Image, and Spatial data type libraries called DataBlades. The Foundation Data-Blade comes with the server; the others are optional. The company also offers the Montage Data Viewer, a tool that allows users to visually navigate data. A hands-on demo gives the impression of zooming through data in drill-up and drill-down fashion.
To learn more about Montage Software and its object-relational database management system, DBMS Editor in Chief David Kalman interviewed Dr. Michael Stonebraker at the company's Emeryville, California headquarters. An edited transcript of the conversation follows.
DBMS: What are the origins of Montage?
STONEBRAKER: It is the commercialization of a University of California database prototype called Postgres. That was one of several research prototypes addressing the fact that relational systems just didn't work outside of traditional business data.
By the early 1980s, it was clear to everybody in the research community that relational databases worked great on business data-processing applications. They were specifically architected in the 1970s to "out-IMS" IMS and IMS-type applications. They worked great on business data processing, but the minute you strayed outside of business data processing they fell on their face.
Pick your favorite nonbusiness data-processing problem, such as GIS (Geographic Information Systems), medical imaging, text, mechanical CAD, or electronic CAD; database researchers looked at these applications and concluded that relational systems didn't work, then invented add-ons to try to make them work.
By 1984 or 1985, it was obvious that we needed to build a new generation database system to address nonbusiness data-processing applications. The Postgres research project started in 1985, and over the next six or seven years we wrote, from scratch, a database system that has a very different architecture than traditional relational systems, and responds to the needs of clients outside of business data processing.
At a university, you have student labor. Students are wonderful at getting code to work, but terrible at documenting it, removing the last bug, and writing front ends. You can only go so far until it's appropriate to do technology transfer and let a commercial venture take over. That's what happened to Montage. We picked up the University of California code, added SQL, fixed the remaining bugs, made it perform about twice as fast as the U.C. system, and added front ends.
DBMS: What are the issues related to developing code in a public university and then commercializing it?
STONEBRAKER: Ingres was developed in exactly the same way in the late 1970s, and both Postgres and Ingres were funded entirely by the federal government. The philosophy of the computer science faculty at U.C. is that things develpoped at U.C. are public domain and available to be taken by anybody. Your $75 or your Internet connection can get you the source code for Postgres. It's been available in that fashion for two years. So anyone and everyone is welcome to the results of government contracts.
DBMS: Is there a connection between the Ingres and Postgres projects?
STONEBRAKER: No. Ingres was my research project in the late '70s and the University of California stopped working on the code in 1978. In 1980, I formed Relational Technology [later Ingres Corp.] to commercialize the code. At U.C., I went on to build a distributed database version of Ingres and when that project wound down, I started work on Postgres.
DBMS: What aspect of the relational model is inherently ill-suited to the nonbusiness applications you want to do with Montage? Is it an issue of implementation or of the model itself?
STONEBRAKER: That's a great question. The implementation of all the relational systems is totally screwed up. But there are also aspects of the model that just aren't going to cut it. So the answer is both.
Here's a simple example that shows one of the problems, using the standard, tired employee example. Employees have a name, an age, and a salary. Suppose you want to find the salaries of all the employees whose names begin with "S," and you want the salaries and names sorted in ascending name sequence. You get names sorted in ASCII order, which works just fine for U.S. names, but suppose this is a French database where an apostrophe is significant and there are acute and grave accents. These names don't sort in an ASCII collating sequence, so you get them in the wrong order. You move into a slightly different domain, and relational database systems don't quite give you the right answer.
The reason they don't give the right answer is that they implement varchar with its associated operators (less than, greater than, and equal to) on ASCII sequences, and French characters are not ASCII sequences. The problem is that character strings are really many different types. They're not one type, and all of the relational systems implement one type.
IMS had a fixed collection of types such as integers, floats, packed decimal, and character string. In the late '70s, the relational vendors just adopted that type system, but, fundamentally, that type system is much too weak to model problems outside of a narrow domain. The type system that [relational] vendors have chosen is anemic beyond belief.
DBMS: The relational model doesn't specify type implementations. ...
STONEBRAKER: Exactly. It's a problem of the implementation. In fact, programming languages such as PL1 had extendable type systems in the 1970s. The programming language community knew a lot about types even then. But the database folks implemented crummy type systems, which survive today. This is a straight problem of implementation.
Put differently, all the commercial relational systems came out of System R (the IBM prototype) or Ingres (the U.C. prototype), and neither project had any programming language expertise. They just didn't implement good type systems. A bad solution has survived to this day, and we should just fix it. There's no commitment anywhere in the relational model to a specific set of types. You simply need many more types than just the four that come with SQL.
The second issue is slightly more problematic. Object-oriented programming languages such as Smalltalk and the Common Lisp Object System have a collection of nifty ideas such as inheritance and user-defined functions or methods. The notion that both data and functions can be inherited, supports complex objects. These are very useful, especially in nonbusiness data processing.
Also, the object-oriented programming language community has good modeling ideas; none of them were things that ever occurred to Ted Codd, or Chris Date, or even Mike Stonebraker. So, in my opinion, one should simply take the interesting object-oriented ideas and add them to a SQL-like system. We call that an "Object-Relational (O-R) DBMS," which is to say, it's a relational system to which the worthwhile object concepts have been added. This gives you considerably more power.
DBMS: How do we "fix" the relational implementation problem?
STONEBRAKER: You've got to build a system that makes no built-in assumptions about what types exist. It has to be a thing we call a "razor," in which "blades" can be inserted. That's the only way you can make the system extendable, and it must be architected in the following way.
You need a "vanilla" SQL parser. Let's say you have a type called "French Character String." If you say, "Find me the salaries of everybody whose name begins with "S'," then the parser must ask, "Is there an operator 'less than' for the type 'French Character String'?" There may or may not be such an operator in the blade library. Metadata in the library describes which types exist and what operators and functions are available for those types. The key difference between the Montage parser and other parsers is that Montage's is completely table-driven by metadata. Other parsers are hard-wired to accept SQL-89.
Also, the optimizer must be table-driven. It needs a database that says which access paths work for different operators. In Montage, you can even add new access methods. For the new access methods, you must enter data in an optimizer table that tells the optimizer what to do. For example, in finding salaries of people whose names begin with "S," the optimizer must decide whether it can use B-trees at all. The person who defines French names, if he wants it to be useful for B-trees, must define the function that corresponds to the operator "less than," and the B-tree access must also be table-driven. All through the system, you have to be table-driven off this elaborate set of this blade metadata.
Secondly, you need to support complex objects, inheritance, arrays, unique IDs, and other object-oriented concepts. For example, in the employee/department example, the standard wisdom is that the employee table has a field called DEPT which is a foreign key, and the department table has a field called DNAME which is a primary key. There's this concept of referential integrity, which says that the foreign keys must be a subset of primary keys in the associated table. The reason for that whole theory is that DEPT and DNAME are character-string data.
Suppose I'm allowed to say that, in the employee table, the field DEPT, instead of being a character string, can have a type "department." It's simply a record in the department table, as opposed to a character string. If the type of DEPT is "tuple in the department table," then referential integrity is automatically satisfied. This is perfectly okay in an extendable type system.
Suppose you add to the employee table another field called COWORKERS, which you want to be a set of employees. You want department to be a department. You want manager to be an employee. You intuitively want these sets of records or individual records to be complex objects. Current relational systems don't support that.
In C++, you can have sets of records as a type. So, in Montage, you can have a set of records as a type. The type of COWORKERS can be "set of employees." The type of DEPT can be "tuple in department." The type of MANAGER can be "tuple in employees." Complex objects are perfectly okay as types. In some ways, it's a more natural way to think of the standard employee/ department example because it eliminates referential integrity.
If COWORKERS is simply a field in the employees table when you:
select coworkers from employees where name = "David";
you get back a set. You ought to be able to:
select coworkers name from employee where name = "David";
and get back the names of David's coworkers. Complex-object support means that you should be able to get back a set, or pieces of that set, and you should be able to cascade the dot notation. In Montage, you get sets as a data type with a cascaded dot notation.
As another example, suppose you get a monthly salary that differs each month. You'd like salary that differs each month. You'd like salary to be an array of 12 integers, then you'd like to SELECT salary[4] to get your April salary. Montage can do this. We support arrays as a data type. In a relational system, you'd be forced to simulate this. In the case of complex objects, inheritance, and arrays, you can simulate them on a relational system with pain and suffering.
DBMS: Vendors have tried the object approach in "object" DBMSs. What's wrong with that approach?
STONEBRAKER: This picture [see Figure 1, page 56] puts all applications into one of four boxes. In reality, applications are a continuum, but it's easier to think of them in discrete boxes. On the horizontal axis, data is either simple or complicated. Read that as business data-processing applications on the left (less complex) and non-business data-processing applications on the right (more complex). The vertical axis shows applications that range from less to more search-oriented.
A standard purchase-order system and an insurance-claims database are very simple applications that use mostly numbers and character strings. There are many instances of very simple types. In contrast, the State of California Department of Water Resources has 500,000 slides (mostly of dams) in its media services library. Employees want to go to the library and ask for a picture of the California delta with a blue heron in the foreground and a sunset in the background. To do this, the department is digitizing the entire library and putting the slides on a Kodak photo CD.
The database will have 500,000 images; however, a Kodak CD image actually has four different images in increasing resolution. So, each slide is fundamentally a complex object. Also, they want to geoposition every slide using a table of places and their x,y coordinates from the United States Geological Survey database, where NAME is a normal character string, but LOCATION is a geographic point-of-type latitude and longitude. Also, each slide has a couple of sentences -- a kind of document -- that describes it. They want to index keywords in the description so they can pick out anything that might be a place, then do a join between the image table and the places table to determine a picture's location. The types in this application are more complicated than those in your standard claims database.
Of the four boxes in Figure 1, the upper left box includes vendors who give you SQL on simple data. That basically describes the relational database market. In the lower right box are the object-oriented database vendors such as Ontos, Versant, Object Design, Objectivity, Servio, and Itasca. They primarily provide persistence in C++, which is to say, they support modeling complex objects using a C++ data model that has inheritance and complex objects. However, in general, if you want to find or update all the employees between the ages of 20 and 30, you have to write a C++ program. There's no search. The user reads an object, operates on it, then puts it back.
If you want to apply numbers to these boxes, the current R vendors, in aggregate, represent about a $4 billion-a-year market, and the current object-oriented DBMS vendors represent about $30 to $50 million. One market is 100 times the size of the other.
We don't consider Montage in either of the two boxes (top left or bottom right) that I've described so far. We consider ourselves in the upper right, which is to say we provide search for complex data. We do not give you persistence in C++. That's fundamentally responsive to the lower right-hand corner. Instead, our primary vehicle for interacting with the database is SQL. We distinguish ourselves from the O companies by being oriented toward SQL, not toward C++.
The R guys service the upper left fine. The file systems service the lower left box just fine. The O vendors service the lower right box just fine. But very few vendors give you SQL on complex data. We do, along with UniSQL (Austin, Texas) and Hewlett-Packard, which has its Open ODB product.
The lower left box ("File Systems") consists of simple data and no search. For example, your word processor reads a document off the disk, you then operate on it, and then you put it back. Basically, it puts things in files. Every text editor I know of is a file-based system. Which is to say, you don't search and it uses simple data. If you don't need to search and you don't have any complex data, then a file system works fine.
DBMS: Do you consider the $50 million object database market a failure?
STONEBRAKER: Obviously. Somewhere around $100 million of venture capital has gone into that collection of companies to produce $50 million in revenue. The venture capitalists think of this market as a total failure. All of those companies are about five years old. By the time the relational vendors were five years old, Ingres alone was at $44 million and Oracle was at $75 million. And they had considerably less venture capital.
DBMS: Will Montage support SQL3 and SQL/MM (multimedia)?
STONEBRAKER: As SQL3 unfolds, we will be SQL3-compatible. SQL3 is the first version of standard SQL that has object concepts in it, and it's extendable. You can add new types and new methods.
In the multimedia area, there are 27 proposals in various stages of wishful thinking. We're still looking at what kind of type library to offer in that area.
DBMS: Why do you see so much potential in the the upper right box in which Montage resides?
STONEBRAKER: The upper right box represents people who currently don't use database solutions at all. The Water Resources application is currently a celluloid application that is moving to computers. GIS applications tend not to use any database solution. Medical imaging applications tend not to use a database system. Our initial customers are almost exclusively moving from no data manager directly into the upper right box. A substantial part of our market will not come from the other vendors.
Also, existing applications will move to the right as they add complex data to their business data processing. Over time, insurance companies, for example, will want to store the picture of the dented car, the diagram of the accident site, and a scanned image of the police report. They'll also want to run a query such as, "Find the 12 most dangerous intersections in San Francisco." Then, if you live within a half mile of any of those intersections, the company can charge you higher rates. I would target the market represented by the upper right corner as several billion dollars, five years out.
DBMS: What is the role of adaptive pattern recognition for searching binary data in Montage?
STONEBRAKER: People are going to write a gazillion pattern-recognition functions. The technology exists today for simple applications. In most of these applications, you must be willing to take errors; for example, if the Water Resources guys can find 100 images close to what they want, they've eliminated 499,900. The technology isn't all that good, but it's not bad. The technology will advance over the next decade.
What you must remember is that digital libraries have relied on human catalogers. A person looks at a picture and enters "sunset" or "low water." That assumes that some human can figure out anything that anybody will ever want to know about an image. That's silly. For example, until six years ago, nobody wanted to know about low water in a dam. [With the California drought,] suddenly it was really significant. You can't presuppose what will be interesting.
The doctor holding up your X-rays wants to find the five patients anywhere in California whose X-rays are most similar to yours, and read their diagnosis and outcome. It's a pattern-matching similarity calculation. The case of finding fingerprints is similar. The Water Resources employees want to find pictures of low water. In California, that means look for blue stuff with a brown ring around it.
Digital libraries of the future cannot possibly depend on human catalogers. In many cases, the data comes in too fast. For example, the biggest digital library application in the world will fairly quickly be NASA's EOSDIS (Earth Observing System Data and Information System). Starting in 1998, NASA will start launching satellites that will collectively beam back to Earth a terabyte of data per day. NASA wants to keep all of for 15 years. This will be a ten petabyte database. NASA recently hired Hughes to build the ground storage and distribution system for it. Thinking that any human is going to catalog ten petabytes is crazy. [Retrieval] will be done by pattern recognition.
DBMS: How does complex object support affect employees or coworkers as "relations" in the mathematical sense?
STONEBRAKER: In a tradditional relational database system, to model CO-WORKERS, you make it a binary relation with pairs of employee names. You model it as a relation. You can certainly do it that way in Montage; but in Montage you get an extra option. If you would like to model it as a set of objects associated with each employee table, that's perfectly okay. As with most object-oriented concepts, you can simulate them on relational systems and the pain and suffering is either low or high depending on what you're doing.
DBMS: How do you optimize retrieval of complex objects?
STONEBRAKER: Let's go back to the Water Resources company example. Consider the query:
SELECT id FROM picture, placese A, places B WHERE Sunset (image) and Contains (A. name, tag) and A. location && B. location and B. name =' Sacramento';
You're looking for sunset images within 20 miles of Sacramento. So Sunset () is a user-defined function that operates on images and returns a binary. You want the tag that contains a name which, in turn, exists in the places table. Read double ampersand (&&) as "within 20 miles of" a second place, which is "Sacramento." In any smart database system, Sacramento is a point. If you have a B-tree index on Sacramento, you can find B.location, which is the specific geographic coordinate (latitude and longitude). Now, I need to find the locations within 20 miles of Sacramento. This is a two-dimensional search, which B-trees won't do. Period. B-trees do only one-dimensional searches, so you've got to have something like an r-tree or a quad-tree or a grid file to do that clause. If you don't have one of these access methods, then that term won't be indexable. We have an r-tree, so this clause goes fast in our system and grindingly slow in any other system that can't index it.
With the Contains() function, you want this tag to contain a name. If you have a keyword indexing system, then Contains() knows about that keyword index. This will go blindingly fast. If this is just SQL, where you find a name inside that tag, then this will be worse than a sequential search. It will be a cross-product join. So, again, it goes blindingly fast, or grindingly slow, depending on whether you have keyword indexing.
With Sunset(image), if you don't have user-defined functions, the image has to go out to an application program to be processed. Then you have to run less than the whole query inside the database system. This runs awfully slow. The only clause a traditional relational database can run is name= 'Sacramento'. Everything else involves types it doesn't understand. You have to code the rest of the query in user space, somehow, and this simulation will be very painful. Montage focuses on applications where the simulation is really painful.
Also, the clause "name='Sacramento'" can be satisfied in 50 instructions. Sunset (image) takes several million instructions. Our optimizer understands that there are expensive predicates and cheap predicates, and we try very hard to do the cheap predicates first. Current relational systems view all predicates as costing the same in terms of CPU instructions. That's just an example of where our optimizer works hard to do something that's different from what current optimizers do.
On the other hand, we've paid no attention to optimizing for TPC-A, which the relational guys have spent the last six years doing. If you have a TPC-A-type application, you should buy from those guys. They have tuned to address that market. We would be foolish to try to compete with them on something they do very well.
DBMS: Who will make DataBlades?
STONEBRAKER: We will write as few DataBlades as possible. We'll find somebody else who has the technology that we need, and license it. We have a Text DataBlade, we have an Image DataBlade, we have a GIS/spatial DataBlade. We licensed the Text DataBlade and GIS DataBlade from other companies and converted them to our DataBlade format. In effect, we are licensing extensions from the application experts who, in turn, get an alternate distribution channel. There will be dozens, if not hundreds, of such extensions. We hope to have a big catalog and act as a publisher of extensions. In a world where there's a lot of blades that go into your razor, there's a big aftermarket of sales possibilities for selling DataBlades.
DBMS: What is the danger in people creating DataBlades with similar function names, but different meanings?
STONEBRAKER: If you buy Montage and you install 50 DataBlades in it, you have an enormous sea of types and functions. You have an unbelievable superset of the SQL available in the current relational systems. One possibility is that every aircraft manufacturer, for example, will have an aircraft type library and they'll all be different. That could happen. My sense is that it probably won't.
DBMS: How does Montage differ from other systems that merge object and relational techniques?
STONEBRAKER: Let's look at Hewlett-Packard's Open ODB. It is designed to service the upper right box, but it's a simulation layer on top of Allbase. It's an upper right corner system as a simulation on top of an upper left corner system. This is what we call "wrapper" technology. The problem with a wrapper is that you have two database systems, one on top of the other, with two optimizers. In the case of running our sunset query, you don't have r-tree access methods to make it go fast. You don't have keyword indexing in the bowels of the system. The wrappers just automate the simulation, but don't solve the performance problems associated with them.
The easiest way for the relational vendors to move from the upper left to the upper right is to write wrappers. Informix has licensed the Open ODB wrapper and is going to put it on top of Informix. And our best understanding of Oracle version 8 is that it's a wrapper on top of Oracle version 7.
DBMS: Does UniSQL fall into this "wrapper" category?
STONEBRAKER: It is not a wrapper. UniSQL and Montage were written from scratch to address this problem area. Your readers should distinguish two kinds of systems. There will be systems written from scratch addressing this need, and there will be wrappers on top of relational systems that will attempt to perform that. Expect a lot of marketing hype from the R vendors about their wrappers, and expect bad performance.
DBMS: On the subject of hype, it seems to me that what you call "Object-Relational" is just a more complete relational system that's optimized in a slightly different way. Is Montage really different from what was intended in the relational model?
STONEBRAKER: That's really interesting. Chris Date was sitting in that very chair about a month ago making exactly that statement; that is to say, Montage has implemented the relational model we had in mind all the time. Our basic idea is to remove the limitations of the type system and add useful object concepts to SQL. If you'd like to think of that as a relational system done right, that's okay. Our marketing pitch is that it's an Object-Relational system. The point is that you need a new engine to do this kind of thing. The other engines will require major rework to efficiently handle complex data with SQL.
DBMS: How do DataBlades differ from Ingres user-defined data types?
STONEBRAKER: My last gasp before leaving Ingres was to persuade them to do the abstract data type system, which is a type-extension system. The type extension in Montage is similar to the type extension in Ingres, but the Montage system has fewer restrictions. For example, in Ingres you can't allocate memory inside your extension. In Ingres, you can't run a query from inside your type extension. Also, Ingres never did complex objects, inheritance, support for arrays, and overloading. They never got around to the object concepts. They have a part of the answer implemented in a very restrictive way.
If they choose to focus on building an O-R system, they have already moved part of the way in the right direction. The problem they and all the other R vendors face (which is one of the reasons I got so frustrated and founded Montage) was that I was talking about the importance of the upper right box, and the people at Ingres were putting all their energy into the upper left corner.
Ingres is in a very demanding marketplace that requires a huge amount of energy to satisfy the needs of the existing customer base. Whenever there was an issue of resources in addressing a new market or making current customers happier, they always decided to make the current customers happier. I'm not saying this is good or bad. One of the problems all the R vendors face is that they have enormous installed bases of very demanding customers. That tends to slow them down in addressing new markets. I think we have a two- or three-year headstart on the R guys.
DBMS: Montage provides a "time travel" feature. Why would you want to view data in time orientation?
STONEBRAKER: In all current relational systems, when Dave Kalman gets a ten-percent raise, the salary bits get overwritten. To ensure you can recover from a crash, you write in the log an arcane, coded procedure walks around in the log and fixes up transactions that weren't committed when the system failed. This is standard write-ahead log technology.
There are several problems with this. First, you cannot instantaneously recover. If the system goes down, the recovery program runs as a two-pass algorithm over the log. Recovering quickly is something no relational system can do. Secondly, if the recovery code fails, you can't recover your database. If that happens on an important enough customer, it makes the front page of The New York Times. The recovery code has to work perfectly. And, by the way, the only way to test it is to fail. This is a software engineering nightmare.
Also, you lose history. If you want to ask about Dave Kalman's salary in June of 1991, that data's gone. The system used to have it, but it went into the log, which was truncated.
Postgres, and now Montage, use a different storage system. When you get a raise, new information is added to the database and your old information stays in the database. There is no log. You can think of the log as integrated into the database by just not overwriting the data. For a while, both the old salary and the new salary exist in the database. The runtime system knows which one is which. At commit time, your old salary becomes available for garbage collection. If Montage crashes, recovery time is a fraction of a millisecond.
Also, you get an extra service. On a table-by-table basis, instead of having the garbage collector just throw old values away, you can add old values to an archive table. Then, you can ask for the state of the table as of any time past. Montage gives you what we call "snapshot" semantics, where you can ask for Dave Kalman's salary as of a particular date. That's very useful in any system that requires a longterm audit trail. In environments where you want to keep the history, Montage keeps it for you automatically. If you don't want the history, then you throw it away.
If you think of every time period as a new version, Montage remembers all past versions of the database. Also, you can have named alternative versions. So, using aircraft as an example, you can have a basic 747 version, then you can have a stretch 747-300. Then you can have the shrunk 747, which is the 747-SP. These can be named alternatives. They can share the common pieces of the airplane, and then only record how they're different. So, we support a tree of named alternatives that are delta-encoded against their parents. Each of those alternatives is, in turn, time traveled. So you get both kinds of versions.
User-defined functions can also time travel. If you add a new Sunset() function and ask for sunsets for last year, you get the old Sunset() function. Rules also time travel. Also, let's say the 1991 employee schema is different than the 1992 employee schema, which is different than the 1993 schema. Time travel means that when you run a query as of 1991, you get the schema as of 1991. We do all of that automagically. We remember past states of metadata using the same time-travel technique. The entire system time travels.
DBMS: Montage seems relatively inexpensive. How did you decide on the pricing?
STONEBRAKER: Historically, all the R vendors and O vendors have sold five-digit software, with five digits to the left of the decimal point. There's a bag-carrying sales-person who's happy to take you to lunch. He doesn't know anything, but he'll take you to lunch. They have products that are difficult to use, so you need a guy in a white lab coat who can figure how to install and tune it. They have expensive customer support, training, and presale support organizations designed to interact with the guy in the white lab coat and to convince you how terrific you are. This is reminiscent of the way business is done on mainframes. PC software doesn't work this way.
Our point of view is that Microsoft, not mainframe vendors, will determine how things will operate. Software in general, and database systems in particular, will be three-digit objects, not five-digit objects. If nothing else, Microsoft will force that to happen. In fact, SQL Server is very aggressively priced on Windows NT.
When we started Montage, we said we could be either part of the problem or part of the solution. So we are pricing in the Microsoft tradition. To do that, you cannot have bag-carrying direct salespeople, and you'd better get rid of the guy in the white lab coat. You have to make the system easy to install. You have to make it self-tuning. Instead of your system coming with many inches of reference manual, you want to focus on online help. Marketing wouldn't let me get away with it, but I would have preferred to say we have no reference manual. We have a reference manual, but it's a linearization of the online help system.
None of our investors thought this pricing was a good idea. They said we were leaving money on the table, which was probably true. But it's very difficult to change from one model to another once you get going. If you have five-digit software, you have to sell and support it in a particular way. The current R guys are going to have a painful transition as they try to move from the five-digit world to the three-digit world. I didn't want to go through the same painful transition.
DBMS: Your price sheet says you don't discriminate against non-Intel platforms. You plan to charge the same amount for Intel, RISC, et al.?
STONEBRAKER: Yes. There is only one price. PC pricing is the pricing for any platform. Right now we run on Sun and we're starting to port to the Unix systems, we're eyeing an NT port, and we're eyeing a Chicago port.