Release of Interbase Beta For Linux

Baudtender was one of the folks who wrote to say that Interbase has been released for public testing. This is the open source release, with the code and more information available at Interbase.com

Comments

Other databases

[AlexA]

Does anyone know how InterBase compares to other open-source/free databases like PostgreSQL, mySQL, etc.?

Re:Other databases

[shadrack]

In addition to the other comments here, it also supports an external event notification system. You can program in events that are received by external processes that have registered for them. Superior alternative to having external processes poll the database for info. It also supports multiple transactions against multiple databases (through the native API, not through the Borland database engine). It has a mature and tested API for both C and Delphi programmers, and there is an ODBC driver available. It supports SQL statements up to 64k in length. It also supports automatic Database shadowing, and allows a single database to span multiple drives.

Now to balance things. Interbase server side User defined functions are not threaded in the current Linux release (5.x). This can cause slow downs if lots of users are setting them off.
On the windows side where IB is truly and fully threaded, UDFs can't make calls to external programs/DLLs (ala SQL Server). Has poor support for temporary tables, though that can be easily overcome with good design and programming.

Overall though, IB is truly multiplatform and very easy to setup and maintain. You don't need a high priced Oracle style DBA to manage it.

Well behaved

[deefer]

Nice. I've used Interbase on NT for the last year, and it's pretty much rock solid. Three crashes last year, full recovery each time - nice.
The real kicker for Interbase is the fact it's so bloody small - it hardly eats any resources. OK, it does lack some features, but you can get around these with a little effort.
As Linux gets ported to more and more embedded devices, there will be situations when a database will be useful. Interbase would plug that gap admirably.
Inprise are to be congratulated on this bold move - I am hoping to see a resurgence of Borland as a market leader in compiler technology. They already are, IMHO, except in market share...

Strong data typing is for those with weak minds.

Try here

[MonkeyMagic]

For a very superficial look at PostgreSQL vs InterBase try this. Taken from the interbase link above.

Open Sores?

[Amphigory]

For the record, the current release is not open source -- despite the fact the linked page has Open Source plastered all over this. In fact, when you download you get binaries only. Remember: Inprise still have not announced what license "Open Source" Interbase is going to be released under.

Watch carefully -- it's libel to be free beer only. (Not that I'm complaining. It still beats the heck out of MySQL for what I do, and I'm not an Open Source zealot) I just wish they would not call it open source until it is open source.

Did I just miss the source code on the web site? Anybody from Inprise care to comment?

--

Faster than MySQL?

[mind21_98]

According to these results, PostergSQL seems more able to support multiple connections at once. Does this mean that the projects that are totally open source from the start are faster? Or is it because Interbase hasn't had time to be patched and/or fixed?

Re:Faster than MySQL?

[KyleCordes]

I think the issue is that they have a "new" architecture and an "old" architecture... the old one is a process-per-db-connection, with no data cache shared between the connection processes. (Obviously this is a remarkably BAD idea). The new architecture is one big "super-server" process (or a few processes, or something like this) with shared cache and all the other obvious stuff.

The Linux code still uses the old architecture. The NT code uses the new.

Re:Faster than MySQL?

[sab39]

Are McDonalds fries better than Burger King fries because companies with two arches as a logo make better fries? Or is it because Burger King hasn't had a chance to update its logo yet? (actually I prefer BK, but you get the point...)

Faster databases are faster databases; whether or not they are open source is pretty much orthogonal to this issue. If you're referring to the claim that open source software is faster, better and more stable, you should be aware that this is a statement about generalities, not specific software. For example, Microsoft Office is indisputably more feature-complete than AbiWord. Now this isn't bashing AbiWord - it just hasn't got to the point of being complete yet. The point is that claims about the superior performance of open-source solutions can only be made in general; if you try to claim that it is true in *every* specific case, there will always be counterexamples (although they will be increasingly hard to find as more open source projects get more and more complete).

Stuart.

Retraction

[Amphigory]

My apologies -- apparently, Inprise have announce the license. Namely, the MPL. This was mentioned in an article I had not seen. However, it still seems odd that they have not yet released the source code.

--

Mozilla Public License

[Andrew Cady]

According to ZDNET, Inprise will "release its upcoming InterBase 6.0 database under the open-source Mozilla Public License 1.1". They're probably just removing all the sexist jokes from the comments before they go public with it.

Interbase and Others

[jallen02]

Okay I have read a few reviews where they stackerd Interbase up to PostgreSQL and talked about the limitation sof MySQL.

MySQL
Good Stuff
Very fast for read heavy or low user-load apps.
Good Security
Good Support with web publishing systems
Not So Good Stuff
No Transaction Support
Table locking system behaves poorly with many connections
Noy SQL-92 Compliant.

Okay a little about interbase and PostgreSQL now. PostgreSQL has a shared cache, something interbase DOES not have in the Linux version as of yet. Interbase blows PostgreSQL out of the water for single user queries.
Interbase TPS on OLTP Single Read test was over 150
The same test for PostgreSQL was at the 50 mark. for transactions per second.

But if you are expecting many concurrent connections interbase does not have the *best* setup and PostgreSQL will actually outperform Interbase under lots of connection/high-load.

Without the shared cache PostgreSQL was like three times faster than interbase. Go PostgreSQL. Another nice thing about Interbase is that it IS SQL-92 compliant. Okay Enjoy and I hope this was a litle useful.
Oh BTW Interbase is under the Mozilla License

(lol I was asked to check out the two database like last eek :-)

Jeremy

Re:Interbase and Others

[_Stryker]

Sorry to burst your bubble, but MySQL is NOT using the GPL. From their website:

NOTE: This license is not the same as any of the GNU Licenses published by the Free Software Foundation. Its terms are substantially different from those of the GNU Licenses. If you are familiar with the GNU Licenses, please read this license with extra care.

This is found at http:/ /www.mysql.org/Manual_chapter/manual_Public_licens e.html#Public_license.

Now they did release an older version (3.20.32a) under the GPL, but that is not nearly the same as releasing the latest versions. This has already been discussed extensively in this slashdot article.
---

Interbase scalability vs. Postgres scalability

[dhogaza]

Postgres beat out Interbase on throughput with many connections because the version of Interbase being released for Linux is the non-threaded version. This version doesn't maintain a shared cache between the separate database processes. Postgres isn't threaded, either, but uses shared memory to cache blocks between backend processes.

Though the released version of Interbase is the non-threaded one, apparently the source for the treaded version WILL be released, and I've seen a quote from one of the Interbase folks stating his hope that folks in the Linux community will port over the threaded version, too.

In that case, scalability shouldn't really be an issue for Interbase, because the threaded version does implement cache sharing between threads.

Postgres reached its maximum throughput on the artificial benchmark at 50 users on a dual P450 with (I think) 512MB RAM, according to the PC Week guy.

Also, note that Postgres v7.0, now in beta, implements some of the missing SQL features mentioned in the article. In particular, referential integrity complete with "on cascade/update delete/set null/default" referential actions is included.

Regarding mySQL, yes, it is very fast for simple queries. For high-volume use it is less than ideal, though, as it implements concurrency control by locking entire tables. Postgres, Interbase and Oracle all implement concurrency control such that readers NEVER wait for writers, and writers only lock affected rows during a transaction (unless the user does a "select for update" or otherwise imposes a more stringent lock ).

Table locking is evil for high-volume sites. This is one reason for Oracle's popularity at high-end e-commerce sites.

Re:Interbase scalability vs. Postgres scalability

[FigWig]

Postgres, Interbase and Oracle all implement concurrency control such that readers NEVER wait for writers...

This is incorrect. Readers must wait when a page (the usual locking granularity AFAIK) is write locked or they could use data that is later rolled back. That would be an unrepeatable read and is bad.

Oh yes, the joys of two phase locking...

Anyone know why PostgreSQL is so slow (relatively) for single users? I heard that the default setting always flushed the cache after a write, but I don't know if this the problem or even if it is true.

Re:Interbase scalability vs. Postgres scalability

[dhogaza]

"This is incorrect. Readers must wait when a page (the usual locking granularity AFAIK) is write locked or they could use data that is later rolled back. That would be an unrepeatable read and is bad."

Sorry, I am absolutely correct. Readers don't see the uncommitted data being written by another transaction, but rather previously committed data, and therefore aren't blocked by writers. It's all done on a row-level locking basis. Postgres and Interbase implement a very similar tuple-storing scheme which makes this (relatively) easy. This scheme is expensive in space, though - in Postgres, at least, you have to manually garbage collect your database with "vacuum" to reclaim space occupied by obsolete tuples. I run it automatically once a night.

Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.

I might be slightly wrong about Oracle, it may block readers of rows being written, anyone know for sure? I know this isn't true for Postgres, though - I've read the source. Writers don't block readers.

You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.

Those of us who support Open Source should be pleased that we have TWO Open Source databases that support write-locking on a row-level rather than block level basis, and that both never block readers when writing.

Postgres was slow for single users on one large benchmark run by PC Week. It's not been investigated thus far. I have some personal theories, though.

Postgres doesn't flush the cache after a write - but it DOES fsynch a table's file at each transaction commit, which in effect ends up being about the same thing. Plans are to implement a full-blown write-ahead log later this year, which will remove the necessity of fsynch'ing data files at commit time. Only the write-ahead log need by fsynch'd. The current fsynch'ing behavior is necessary to ensure that data is flushed to the disk before the separate transaction log is written marking the transaction complete. Again, a full write-ahead log will speed things up by removing the need to do that.

Re:Interbase scalability vs. Postgres scalability

[FigWig]

Sorry, I am absolutely correct. Readers don't see the uncommitted data being written by another transaction, but rather previously committed data, and therefore aren't blocked by writers.

I guess my background in DBs is overly academic :) Heh, and my professor worked on PostgreSQL at Berkeley and at 2 major DB companies. I just always pictured it as a single, shared buffer pool/cache in memory, which was both read from and written to. I guess I need to bust out the PGSQL source tarball.

Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.

Of course rollback doesn't effect committed transactions, which is why I questioned letting dirty pages get read before commiting.

You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.

I don't know what post you read, but I never insisted that all DBs use page-level locking or that it is necessary for proper serialization. I just stated that in my experience, it is very common, because it provides good transaction throughput. What are the benefits from row-level locking?

My I'm feeling defensive this afternoon....

Also check out www.interbase2000.org

[shadrack]

If I understand what I've been reading lately, Interbase2000 will be the new company handling the new open source version of Interbase. It is also the home of the new Interbase Developers Initiative, so coders, developers, writers, users... are invited to join in and have a direct impact on future development. Some of the best IB people in the world are already part of it.

Re:Thoughts on the Interbase Demo

[rm -rf /etc/*]

What they hell did he say?

Relational Databases Considered Harmful

[Kaufmann]

They are. But don't take it from me, mind you - take it from the (in)famous Mr Henry Baker, in this incredible letter (*) to the Communications of the ACM, which is guaranteed to put a smile in the face of everyone who's ever thought there must be a better way.

(*) Note that Netcom, which hosts Mr Baker's archive, is under a large load, and may take a few attempts to be accessed.

V6 has the shared cache.

[Dacta]

Interbase 6 (the one just released as beta) is available with the shared cache under Linux.

That's despite what it says in the article about it not being ready - it seems they finished it after all did. (I'll try and find a link for this)

That should make quite a difference as demonstated by this (from teh PC Week article)

InterBase is clearly a very well-tuned product when given enough memory. As a comparison point, we also tested InterBase using 65,536 cache pages of 4,000KB each in a single-user test; InterBase pushed through 139 tps (transactions per second) compared with PostgreSQL's peak result of 74 tps at the same cache size.

Also, see this quote:

Our benchmark results show clear advantages to both products under different types of workloads. InterBase was significantly faster than PostgreSQL on both simple reads and complex joins on single-user tests, which is how database-enabled Web sites usually access databases. These results indicate an efficient query parser, optimizer and data page seek algorithm

I'm just looking forward to them getting it up on Sourceforge!