back to article Postgres pioneer Michael Stonebraker promises to upend the database once more

What if we built the operating system on top of the database instead of the other way around? It sounds like an idea from an undergraduate student after one microdose too many, except it's not. It's a serious idea from someone who has already upended the computing industry and whose influence has spread into familiar products …

  1. A Non e-mouse Silver badge
    Pint

    From the headline I thought it was another attempt at WinFS. Then reading the article I thought it might be a bit more liike etcd.

    But reading their overview, they're talking about a microkernel to run the RDBMS and then the applications run on top of the RDBMS.

    I find it an interesting concept for cloud-type workloads. I wish them the best of luck.

    Icon: 'Cause it's the season.

    1. Doctor Syntax Silver badge

      With Stonebreaker involved it was never going to be another attempt at WinFS.

    2. elsergiovolador Silver badge

      I find it an interesting concept for cloud-type workloads.

      Something you would run on someone else's computer, but not yours?

      That doesn't sound good :-)

      1. Crypto Monad Silver badge

        You can run "cloud-type workloads" on your own hardware.

        The term I believe is intended to describe workloads that are broken into lots of similar pieces that run concurrently across multiple servers so you can scale them up.

        Kubernetes is an obvious example of this.

    3. the spectacularly refined chap Silver badge

      There have been several attempts over the years. WinFS is a prominent recent example. The main historical one would be Pick which still has a few niche users. There are other examples e.g. Apple NewtonOS comes to mind with its "soups" and "stationery".

      1. Anonymous Coward
        Anonymous Coward

        I’m not sure many, if any users of Pick and its variants are still using it this way. More likely they are using Unidata, Universe, or one of the other flavours on top of a traditional O/S. Original Pick and it’s variants such as Reality and ADDS were very much of the model described though.

    4. Steve Channell

      lets do the time-walk again

      The idea is far from new, and mirrors work done for IBM future system project (that eventually became the System/38 minicomputer then the AS/400), Pick, Mumps and yes WinFS.

      It's also been a long time since File-systems were simply hierarchical directories for files stored on disk volumes, they've evolved into specialist databases in their own right.

      If it's not new, the real questions are [1] what's different this time? [2] why do we need it? [3] will its performance justify the change? [4] is it better than other initiatives?

      It's different because PostgresSQL and advanced file-systems are open-source, stable, modular and implement stable APIs - combining both functions is an engineering problem.

      Why is more difficult because we no longer use raw-volumes to host high-performance transactional databases - Asynchronous IO and unbuffered file access largely eliminates FS overhead

      Performance advantage of combined scheduling, memory management and indexing can only be achieved by moving the DBMS kernel into the OS kernel, but that means removing triggers/procedures or introducing a fresh attack surface for hackers

      Developments around CXL Memory, pooled memory and memory semantic SSD are adding index technology to memory devices with GPGPU executing search functions - maybe the convergence of the future is database/memory not database/operating-system.

      1. Rob Isrob

        Re: lets do the time-walk again

        "Why is more difficult because we no longer use raw-volumes to host high-performance transactional databases - Asynchronous IO and unbuffered file access largely eliminates FS overhead"

        This is wrong. Especially today as table stakes for IO response time is getting smaller. I've been involved in storage migrations that involved IO going from half millisecond to millisecond and it impacted perations. You can't traverse "another" stack on the way to updating DB records without slowing it down. Similarly, we see now how AWS is doing a sell on S3 being faster. You read crap like this: https://blocksandfiles.com/2023/11/29/aws-s3-express-one-zone/

        "AWS Chief Evangelist Jeff Barr blogs that latency to the first byte is in the single-digit milliseconds area compared to S3 standard, whose latency is described as milliseconds"

        Wow...ready for some hot DB action there cries the marketers! Maybe for somebody that lives in the sticks and isn't used to less than half a millisecond.

        1. Steve Channell

          Re: lets do the time-walk again

          I've designed databases schema for DB2, Teradata, Oracle and SQL/Server. Raw volumes were introduced for Sybase, Oracle and others because (at the time) Unix only provided buffered synchronous IO. DB2 never needed raw volumes because VSAM datasets were always asynchronous and translation from VSAM page address to cylinder, track, sector imposes little overhead.

          I was skeptical of SQL/Server dropping raw volumes in the migration to NTFS (from OS/2 to NT), but direct async IO and list IO reduced the performance advantage. The biggest distinction now is that databases don’t need journaled files-system – Oracle ASMLib and MS Storage Space Direct avoid this but are still logically file-systems.

          You’re right that NAS storage and S3 will never be as fast as a raw volume.

    5. Groo The Wanderer

      Actually, it sounds very much like an AS400 from what my co-workers described the system as 20 years ago...

    6. david 12 Silver badge

      Not unix

      I thought of Pick first, but then I realized that what they're actually talking about is "not unix".

      The unix that was released to universities was the version without any native database at all, that could only implement database functionality at the application level, and generations of programmers have grown up with the idea that this was normal and ordinary.

      Actually of course, the opposite was true: commercial computers were tabulating machines, not just calculators. IBM is one example (they started as a database company), but the same was true for GE and LEO and everybody else.

  2. elDog

    Didn't Microsoft already play with a DB-based OS? And how about MUMPS?

    I can't remember the codename for the MS effort but I thought that it floundered because of, again, performance issues.

    MUMPS is a forgotten multi-user language/platform that saw a lot of usage in the 70s-90s and is reported to still be used in a large percentage of US hospital systems.

    1. sarusa Silver badge

      Re: Didn't Microsoft already play with a DB-based OS? And how about MUMPS?

      That was WinFS. It was part of the 'Longhorn' bunch of technologies that was going to make Windows Vista the greatest OS in the world for all time!

      That was a little less ambitious, though, it was just going to be a database for the filesystem, not for the entire freakin' OS.

      I trust Stonebraker to be able to pull this off more than MS, though. He's had far fewer Vista and Windows 8 moments. And to be fair to MS, Windows still has some 1980s and a lot of 1990s code in it. It would very very hard to retrofit those millions of lines into something like this and all the apps would break anyhow, which is something MS can never do. You're much more likely to see this first as a little proof of concept OS, then if people like it it might start expanding outward. Decades away from wide practical use, if ever.

      1. ldo Silver badge

        Re: Microsoft Never Breaks Apps?!?

        Where does this myth come from that Microsoft never breaks apps? That happens with every major Windows release, which is why so many people try to avoid upgrading.

        1. Arthur the cat Silver badge

          Re: Microsoft Never Breaks Apps?!?

          Where does this myth come from that Microsoft never breaks apps? That happens with every major Windows release, which is why so many people try to avoid upgrading.

          I think the MS approach is to never intentionally break apps. They just accidentally break apps and/or change the interface so drastically that they're as good as broken.

        2. sarusa Silver badge

          Re: Microsoft Never Breaks Apps?!?

          Yeah, MS does break apps left and right, but they're actively trying not to - unlike MacOS or Linux (which I also use). MS's backwards compatibility is freaking amazing. I recently just ran a 1995 executable on my box last week and it actually still worked.

    2. An_Old_Dog Silver badge

      Re: Didn't Microsoft already play with a DB-based OS? And how about MUMPS?

      InterSystems had a MUMPS-like database called Cache. Currently, their home page pushes a different database they call "Iris", and while there's a blurb talking about how wonderful Cache is, there's no clickable link on their web page by which someone might learn more about Cache, or actually buy the product.

  3. Tom Chiverton 1 Silver badge

    So, it's IBM i then?

    1. Arthur the cat Silver badge

      So, it's IBM i then?

      Came here to say that (although I'd have spelt it OS/400).

      1. Michael Wojcik Silver badge

        Not really, at least based on what's in the article.

        OS/400 (and now i) has an integrated RDBMS and it has single-level store, where everything's some sort of object in a single space. But the SLS isn't typically addressed relationally by most applications. In particular, applications don't adhere to any sort of normal form in addressing most OS/400 objects other than database rows.

        An RDBMS OS would push relational structure and operations down to lower levels of the stack. As such, it's suited to particular use cases; it's not a great approach for a wide range of tasks. That's partly why WinFS wasn't successful, and why the PICK family (which is still around, though apparently mostly as MultiValue DBMSes rather than the full PICK OS) drifted away from being a full OS.

        1. HangingOnAnotherDay

          IBM i RDBMS is "integrated" but your context seems to imply it is a separate product. It is not. It is built into and along with the OS. Integrated including into the native languages with full support for SQL. More "integrated" therefore than any other system on the market today or ever. And as a result the RDBMS is "down to lower levels of the stack" as you described as being desirable. Note that IBM refers to the RDBMS as DB2 but that is a marketing game. It is not a separately installable product because it is part of the OS. And has been since System/38 delivered in 1980.

          As for "But the Single Level Store isn't typically addressed relationally by most applications" that would be because addressing objects relationally would be silly. Objects are referenced by name - as is true on any system except the most arcane that required direct addressing - and the OS handles locating the named object via it's object directory (not a directory file system). All data (whether true relational or, in some cases, flat files) is stored in the RDBMS in a table - with a few optional exceptions for small volumes of non-relational data.

          All entities (tables, views, indexes, executable programs, etc.) on the system are objects and all have an object type that defines their behavior and characteristics. Unlike uncontrolled directory file systems, such as in Windows, an object cannot be forced to do something it is not defined to do and cannot be changed to a different object type, as can be done in Windows.

          Most who have not learned the system simply do not understand it. I wish more IT professionals would take the time to understand IBM i and it's capabilities. We get so caught up in "open" systems and what we already know that we don't often spend time learning other systems.

      2. I Am Spartacus
        Childcatcher

        Well, no, its more than that

        If you have every admistrated and As/400 system you will have realised that SLS is a double edge sword. It is wonderfully easy to work with. It is responsive giving you near linear access times to any data, where as directory designed storage (think VMS, Linux, Windows) you have to navigate the directory tree.

        But weher it breaks, and breaks very badly, is upgrading the storage. Our system used RAID-5 as the underlying disk access, but implemented in hardware. To add a new array of disks you have to shutdown the system, off load the data to tape, add the new storage, reconfigure the RAID system and then restore data from tape. When you have a couple of 100 GB of data on a year 2000 version of AS/400 with DLT as a backuop, that is painful. And risky!

        I think this is one of the lessens that Stonebreaker is bound to address.

  4. Doctor Syntax Silver badge

    I always reckoned that some file systems owed a lot to whatever was the current database technology at the time they were designed. Basing the entire OS on a database is, I suppose, the next logical step.

    1. An_Old_Dog Silver badge

      Database-based OS: One Question

      When (not "if") the database is corrupted, how would I recover my files from such a beast? (I hate black boxes, and "Just reload from your backups" is not a sufficiently-good answer for my purposes.)

      1. WBrianWhite

        Re: Database-based OS: One Question

        When (not "if") the file system is corrupted, how would I recover my files from such a beast?

        When (not "if") the registry is corrupted, how would I recover my files from such a beast?

        Somehow people muddle through

        1. An_Old_Dog Silver badge

          Re: Database-based OS: One Question

          I, and at least a few other people, simply avoid the Registry corruption problem by running non-MS-Windows operating systems.

  5. HighHair

    Stop day dreaming - get back to work

    Yes...well that's all very good...

    ...but how about you first concentrate on expanding SSPI to resolve LDAP group authentication from PostgreSQL without some shitty plug-in.

    1. Ken Rennoldson

      Re: Stop day dreaming - get back to work

      That's not a bad point as there are two issues that need to be resolved, state and identity. Do they resolve into a single problem?

  6. Anonymous Coward
    Anonymous Coward

    So, he's reinventing Pick?

    Pretty sure he's describing Pick.

    1. Michael Wojcik Silver badge

      Re: So, he's reinventing Pick?

      No, because MultiValue is not relational. At least not as used in Pick, AIUI.

      That one thing has certain attributes of another thing does not make them identical.

  7. mrcreosote

    So, he's reinventing Pick?

    Sounds like he's describing Pick.

    1. ldo Silver badge

      Re: So, he's reinventing Pick?

      Precisely. And somebody else mentioned Microsoft’s attempt. Like microkernels, it’s not a new idea. And like microkernels, every time it’s reinvented, people discover why it’s not such a good idea.

      1. ChoHag Silver badge

        Re: So, he's reinventing Pick?

        Usually it's not a good idea because the people doing it haven't already learned all the ways the underlying technology can cut you.

        Here, that is not the case.

  8. Bebu
    Windows

    Blast from the Past

    Just consigned my copy of

    "The INGRES papers : anatomy of a relational database system" Michael Stonebraker, Addison-Wesley, c1986.

    to the charity shop along with various Chris Date's titles.

    I was wondering if the authors were still... aah... extant. So at my age this article was a pleasant surprise.

    The INGRES papers are worth reading today if only to realize a lot database stuff was pioneered a very long time ago.

    The chapter on distributed databases is a peek into another world - networking pre TCP/IP and I think pre ethernet with the database components running on pretty basic DEC PDP-11s (and pre BSD Unix I think.) Your TV remote control probably has more grunt than those PDP-11s.

    The comparison between sql and the ingres native quel is also interesting as quel was (still?) arguably better technically.

    1. Roo
      Windows

      Re: Blast from the Past

      I built "University" Ingres from source a very long time ago (maybe early 90s) only to find that the buffers holding pathnames were *very* short - causing lots of really interesting failures when you tried having your DB reside somewhere like /home/me/foo/bar/wibble. So yeah - it was definitely coded for a PDP-11 vintage UNIX. :)

      IMO there haven't been many (if any) major strides forward in Comp.Sci since the 70s. It's not all bad there have been plenty of useful (and good) refinements since then though !

      1. the spectacularly refined chap Silver badge

        Re: Blast from the Past

        Most recent truly fundmental advance in my view would be skip lists whoch were 1990 if memory serves. Prior to that public key encryption. I'm trying to think of anything more recent, but no even most networking and synchronisation algorithms are a lot older than you might think. It's interesting at times to look at how quickly the true fundamentals in place - by the end of the 50s mosts of the classic data structures and algorithms were in place barely 10 years after the Baby first ran.

      2. ldo Silver badge

        Re: Blast from the Past

        Here’s a pretty major one, from the history of Unix: the Berkeley Fast File System was invented in the early 1980s, and it took file I/O from only being able to utiliize 2-3% of theoretical disk bandwidth up to more like 47%.

      3. ldo Silver badge

        Re: Blast from the Past

        Another one: the “Timsort” algorithm.

      4. ldo Silver badge

        Re: Blast from the Past

        Also: decent garbage-collection algorithms, first for LISP, then later for Perl, Python, Java, JavaScript etc.

        1. Anonymous Coward
          Anonymous Coward

          Re: Blast from the Past

          Java has decent garbage collection? When did that come in?

          1. ldo Silver badge

            Re: Blast from the Past

            Decent garbage collection seemed to appear sometime in the 1980s. The early commercial LISP machines, for example, didn’t have it: users typically ran their programs until the system ran out of memory (apparently this could take a few hours or a few days); then when it stopped, they dumped it to disk, reloaded it, and started again.

            Considering how old LISP was, I expected this sort of thing to be a solved problem by the 1970s. But apparently not.

            1. CRConrad

              I think you missed the sarcasm in the post you replied to.

              A follow-up question in the same vein that might help you re-interpret it would be something like, "If decent garbage collection appeared in the 1980s, shouldn't Java have it?"

              HTH!

    2. rafff

      Re: Blast from the Past

      " quel was (still?) arguably better technically."

      It took SQL a long time to catch up technically with what quel could do from day 1, e.g. update a table with data from a different table. The underlying problem is that SQL was designed for Cobol programmers, and such folk do not generally understand set theory, recursion, data types, or many other concepts that we geeks took in with our mother's milk.

      I first used quel around 1982 in what I think was the first ever commercial RDBMS-based application (analysing market research data). When I was forced to move to Informix and Oracle I found it to be a great leap backwards. It took about 15 years to for SQL to catch up, and its syntax is horribly convoluted; no two implementors implement quite the same syntax, or with the same semantics. Mind you, for several years I made a good living out of those incompatibilities.

      I never used Pick, but the people I met who did really loved it.

      1. ldo Silver badge

        Re: SQL vs COBOL

        SQL was not designed for COBOL programmers. SQL was created by IBM, who had no great love for COBOL in the early days (since they had no hand in creating it).

        In fact, SQL was never a great fit for COBOL. Remember that COBOL was supposed to be focused on “business” needs, and “business” at that time saw no need for good string handling. But with SQL, you need to be able to synthesize query strings on the fly. So all kinds of nonstandard extensions had to be tacked on top of COBOL to cope with this.

        1. Michael Wojcik Silver badge

          Re: SQL vs COBOL

          But with SQL, you need to be able to synthesize query strings on the fly.

          Not if you use prepared statements.

          But in any case, COBOL-74 (and possibly even COBOL-68?) included the STRING statement, which works just fine for this purpose. Since SQL itself only appeared in 1974, the problem you're describing never existed.

          I don't know when SQL precompilers for COBOL and EXEC SQL first appeared, but these days that's how many COBOL applications use SQL, and string formatting is not an issue.

          1. ldo Silver badge

            Re: SQL vs COBOL

            You say the problem “never existed”, then you mention “SQL precompilers” and “prepared statements”. If they were not solutions to a “problem” which supposedly “never existed”, then what were they?

            1. Anonymous Coward
              Anonymous Coward

              Re: SQL vs COBOL

              The problem that pre-compilers and prepared statements solve is "How do you present an SQL statement to, in this case, Db2?"

              The problem that never existed was the "need" to synthesise those statements on the fly. Although you can if you want to.

              1. ldo Silver badge

                Re: SQL vs COBOL

                There seems to be a gap in imagination here: if you don’t want to synthesize queries on the fly, then how do you deal with variable numbers of selection criteria? For example, this sort of thing is common in interactive user queries.

  9. Denarius Silver badge

    BEOS

    Didnt BEOS developers try something like this and fail like WinFS ? Does sound like Pick and similar to an unreleased version of Unix used only inside AT&T with native DB calls in kernel. SNOBOL springs to mind also back on 8086 chips but may well be faulty recollection. With his track record, the results should be interesting.

    1. Charlie Clark Silver badge

      Re: BEOS

      The BeFS pretty much succeeded: it didn't turn the FS into a database but it made extensive use of file attributes and metadata which meant it felt like a database. For example, the headers of e-mails were exposed as attributes and visible in live queries. This is turn meant applications didn't need to invent their own database and queries. There is a downside to this, of course, because node monitoring introduces an overhead to all file operations as the index is updated. In general, this was not noticeable but, of course, any operation with lots of small files is noticeably slower than on other systems.

      Dominic Giampolo wrote a book on the subject and I'm pretty sure that some of the ideas went into Apple's file system which supports queries without routinely trashing the disk to update the index, which Windows still seems to manage.

      1. A Non e-mouse Silver badge
        1. yetanotheraoc Silver badge

          Re: BEOS

          The File System Construction Kit

          https://web.archive.org/web/20170407151632/http://www.nobius.org:80/~dbg/fs-kit-0.4.tgz

    2. An_Old_Dog Silver badge

      Re: BEOS

      SNOBOL was a string-processing language implemented as macros. It was used extensively at Bell. There was/is a version for x86, designed for DOS, but it probably will run on WinNTx as it is a terminal-window-type program. There was/is a derivative of SNOBOL called SNOCONE, which includes structured programming elements.

  10. HuBo Silver badge
    Go

    Self-modifying PrologSQL

    Cool interview!

    With Prolog programs consisting of queries run over rules and facts stored in some database (knowledge base of relations, assertions, and functions), wouldn't there be an opportunity to use PrologSQL (rather than plain vanilla SQL) to develop the DBOS, with automatic application of the resolution principle, and backtracking-oriented constraint satisfaction and optimization functionality?

    The ability to modify data stored in relational tables could result in a form of non-monotonic reasoning for which an appropriate truth-maintenance-system would obviously need developing. But the resulting OS could be most awesome! No? (especially if it can handle Geographic Information System/GIS data and tasks too!)

    (Note: I've dowloaded the DBOS paper and searched it for Prolog to no avail. Closest I found was a ref to Andrew Prout's work at MIT Lincoln Labs. Prout is most "rigolo" in French ... eh-eh-eh!)

    1. An_Old_Dog Silver badge

      Re: Self-modifying PrologSQL

      @HuBo: are you the son of "amanfrommars1"?

  11. Anonymous Coward
    Anonymous Coward

    No, not Pick

    This proposal is not like Pick at all. As a commentar said, here you have something like a microkernel featuring a RDMS usable by every OS feature (scheduler given as example), while the basis for Pick is a virtual memory system mapping the whole disk space, upon which a file system usable as a (not relational) DB is built. But resource allocating features of OS manage their stuff their own way.

    This is what I saw as member of the OS team of a vendor of Pick machines.

    1. ldo Silver badge

      Re: No, not Pick

      But if every file in Pick is a database (as it is), that would include files used by the OS itself, would it not? So the concept of a database is indeed baked very deeply into the foundations of the system.

      1. Anonymous Coward
        Anonymous Coward

        Re: No, not Pick

        Yes, and no

        Example of yes: Account definitions are in the file system, you can perform DB actions on them

        Example of no: Scheduling is defined inside its own code. I even saw implementations where it used another CPU architecture that remainder of OS (kinda user/kernel contexts separation on steroids)

        BTW, DB access is more a layer built upon a file-system architectured for that purpose, but what is nice is that a command can be defined so that a DB selection occurs before actual command code starts executing

        (same anonymous as "No, not Pick" post)

  12. FranckPachot
    Alert

    "You can take a PostgreSQL application, and drop it on CockroachDB" - > Bad example, CockroachDB is the only one within the databases mentioned that cannot do that. It is limited to wire compatibility which is protocol and some features syntax. But no stored procedures, no extensions, not all isolation levels. Your PG application will not behave the same

  13. bombastic bob Silver badge
    Devil

    Just saying something nice about PostgreSQL

    almost 2 decades ago I was messing with open source databases (having once written one, wanted to use something with more/newer/better features and maybe just fix it if it is too slow) and I focused my attention on 2: MySQL and PostgreSQL.

    I found PostgreSQL to be superior for a couple of reasons:

    * it conformed better to SQL standard, particularly with respect to embedded quote marks in text data

    * It was MUCH easier to just set up and start adding data

    Basically I use PG for everything that requires SQL and make sure that it's supported with any system or ISP I need to work with. Now that it is the MOST popular this should become easier.

    1. ldo Silver badge

      Re: Just saying something nice about PostgreSQL

      To be fair, standard SQL does some things with quote marks that look pretty strange today. Like using double quotes around table/field names so they won’t clash with reserved words. MySQL/MariaDB by default uses backticks for this purpose, though you can set “ANSI_QUOTES” mode if you want to adhere to the standard.

      SQLite manages to support both styles without any mode-setting. If you can write your SQL to be compatible with both MariaDB and SQLite, there’s a good chance it’ll be compatible with anything. ;)

    2. david 12 Silver badge

      Re: Just saying something nice about PostgreSQL

      I remember the "SQL standards" insults, particularly from the Oracle camp. First the system I was using was "non standard" because it was too good (the new standard had not yet been released). Then suddenly those features were OK, and it was inferior for the opposite reason. No thought at all about what was actually useful, or common, just an excuse for snobbishness.

      Primed me for the later Browser wars.

  14. Michael Wojcik Silver badge

    Vertica

    Stonebreaker also created the first version of Vertica, a column-oriented DBMS.

    1. lamp

      Re: Vertica

      Please, it's Stonebraker.

  15. Don Casey
    Holmes

    Precedent?

    One could argue that, in the mainframe world, IBM's CICS is a predecessor to this approach. It allowed/required application code to make all 'system' calls to the container (CICS), not the underlying operating system. Mainframe architecture forced this approach, so that CICS could maintain control of the processor and internally dispatch the multitude of threads it was managing. This meant replicating Opsys functions such as memory management, timers, file access, and task dispatching. It was only when there was no internal work ready to run that CICS (and IDMS) would issue a 'wait' and free up the TCB/thread/processor.

    CICS is not a database, it is a teleprocessing monitor of course, but Cullinet's/CA's/Broadcom's IDMS-DC is both a TP monitor AND a DBMS. IDMS-DC is architecturally similar to CICS, with the addition of the DB component to the mix. The system definitions for both the DB side and the DC portions are stored in a database (called the 'Dictionary', but no different in form than a user database). CICS has been around over 50 years (longer than Ingres), IDMS-DC more than 40 (but commercialized in bulk to the existing IDMS-DB user base while Ingres was still a pup).

    Both CICS and IDMS-DC provide 'system calls' for memory management, file access, etc. Those calls are generally processed internal to the container, using a pool of resources obtained from the operating system.

    One could contemplate an approach where the 'few' operating system functions and batch processes these systems need being folded into the DB itself.

  16. Mikemilleresq

    Flex.

    The Markov chain flex in this article is beautifully done and ignored.

    1. HuBo Silver badge
      Windows

      Re: Flex.

      Beautiful indeed, for the non-lossy-database stochastic recall LLM! Ready to train through web slurp, and willing to output customary solecistic sophistry. As a bonus, the identity matrix returns whole NYT articles, verbatim ... (very nice examples at https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-dreadful-december-shows-flaws-of-taking-data-without-consent )

  17. Paul Hovnanian Silver badge

    Yeah, no.

    OS and application data as DB tables has its advantages. If your application model happens to fit one of the pre-existing schemas. But once you have a novel application, stepping outside that model can be painful.

    Current systems (OSs and apps) that use the lowest level of persistence (binary blobs) depend on smart developers to pick the correct technologies, libraries and data structures upon which to build. Some do. Others stick us with crap. But either way, the application is responsible for doing a lot of translating between underlying data stores (XML, JSON, SOAP, CSV, full blown DBMS systems or some cobbled together file format) to talk to anything else. Some do well, others not so well. An OS on top of a DBMS system will remove a lot of that heterogeneity and the effort it requires. Right up to the point at which someone has a new idea that doesn't fit the current data/object models available. Then, it's back to the drawing board, but with a much smaller spectrum of tools available. Because most devs just use the native DBMS and APIs.

  18. Kev99 Silver badge

    At the county where I worked the local welfare department decided to install from scratch a new financial database. They chose Oracle. Five years after they started the process, when I retired, it still wasn't functional as planned, would talk to the chief fiscal officer's financial and payroll systems without thousands of lines of interface code and had cost millions.

    1. Claptrap314 Silver badge
      Trollface

      "Guaranteed to increase business"

  19. Cardinal Fang

    The catch is

    The database has to be more reliable than whatever it's replacing.

    Fairly hard to beat direct memory addressing in the kernel or a filesystem on disk.

    I'm not saying the idea is bad but it's been tried before and not being robust in the face of [memory | disk] errors has been the problem.

  20. Anonymous Coward
    Anonymous Coward

    How Do You Coun?

    Quote: "...PostgreSQL ... which, for the first time, became the most popular choice of database among developers this year...."

    Define "popular"!! My guess is that there are gazzillion more SQLITE3 databases out there, compared with the number of Postgres instances!

  21. n0npr0ph3t

    Wrong Calendar

    The reporter wrote "Julian calendar" when they must have meant "Gregorian calendar". For the most part, only orthodox churches still adhere to the Julian calendar which was replaced by the Gregorian calendar in 1582.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like