Oracle Berkeley DB Reviews

I use the solution in my company for my production projects. I have had hands-on experience with Oracle APEX and have done some research about it to figure out if it is suitable for my next project or not. I use Oracle Berkeley DB for normal MVC projects. We get some sort of data from the users, then we put them into the database, and after that, we do the query from there, so it is not a big deal.

The most valuable feature of the solution revolves around something known as paging. Oracle is the best among the other products in the marketplace, especially in terms of stability and performance. The tool's performance is good, and I don't have any problems with it. The reason that we chose Oracle is because we don't want to have those headaches with other products in terms of performance. We use Oracle RAC and Oracle Berkeley DB along with most of the things that are used in production with the DBA of that project. I am the designer and the architect of the applications in my company.

One of the things that I want to see in Oracle Berkeley DB is a driver for reactive programming. I think the tool's official driver for reactive programming, especially for Java, is the thing that Oracle needs to be more agile in, specifically in those areas of programming that other products are currently going into. Other tools have become more innovative in many areas. I know that Oracle has many responsibilities in maintaining the situation with the current projects and so on. I think it would be very cool if Oracle could make improvements to its projects, as it can help me with my current projects. One reason why I don't choose Oracle Berkeley DB is because we want to go for reactive programming, along with Project Reactor from Spring, but we don't have the official driver for it.

I have experience with Oracle Berkeley DB.

The tool's stability is very good because we don't have any complaints about any data loss, and most of such areas are used in EVA DB. I don't have any problem with the product's programming area.

It is a scalable solution. The people involved in production in our company really like the product.

The production team in my company uses the tool.

The product's initial setup phase is not so hard for me to integrate the database and drivers. It is a straightforward process. At my company's programming level, we had no problems with the tool.

There is a need to pay for the licenses and features of the tool. It can help other people use the tool properly.

Giving out some free subscriptions and offering some premium plans for enterprise solutions that Oracle presents to the audience can help other people who want to use it. Being more agile in adapting to the new features that other DBMS tools and NoSQL Database Engines offer to the users can be helpful.

In terms of the tool's replication features, one thing you will have in your marketplace is Oracle RAC. When you use Oracle Berkeley DB as a standalone database, we have some problems in replicating such data.

Actually, at the programming level, I don't have so many problems integrating the databases. At the production level, we actually use the Oracle RAC for our project. Actually, in those areas, I don't have any problem with the tool either.

I rate the tool as an eight or nine out of ten.

The product's interface could be more intuitive and user-friendly.

I've been using Oracle Berkeley DB for about a month now.

I would rate the stability around five or six. It has been stable. 

I rate the product scalability around eight, although I haven't extensively tested it.

I used MySQL before Oracle Berkeley DB.

It took around 15-30 minutes to deploy Oracle Berkeley DB. 

I rate the initial setup process a seven, as the user interface was a bit confusing during the setup process.

I rate the product's pricing a five out of ten. 

The product meets all the essential business requirements. I rate it a six out of ten.

• Transactional data store
• Concurrent data store

This product helped us to develop a performance-critical DB backend module in the healthcare domain.

Environment corruption is a common problem found when a DB environment is used by more than one process on a machine at a time. Another thing is that an entire page will be locked when updating a record. This will cause locking of other records on the same page. This can be improved a bit more.

I used it for two years, about nine years ago.

When multiple processes are holding handles to same environment, then there is a high possibility that the environment handles might get corrupted and the whole connection to various databases need to be recreated on the fly. This will also cause ongoing DB operations to get terminated. One solution to this problem is to design the DB access mechanism in such a way that only one process (we can call it a server process and it can be a COM server) is holding the database environment handle and all other client process should communicate with this server process to read/write DB records.

There was excellent support in the Oracle Berkeley DB forum. Also, we had an opportunity to talk to a Oracle Berkeley DB technical person in their Japan office.

We had a previous solution. Because of its proprietary nature and non-conformance to our performance requirements, we considered this product.

Initial steps were pretty straightforward.

We were an in-house team. Things such as database page size, locking model, etc. need to be carefully chosen and designed. A prototype development model would be highly effective.

Since I am a technical person, I don't know any good details about pricing.

Because I was primarily concentrating on the performance side of this product, one will have to first benchmark their own performance requirements. Next, consider concurrency requirements. Then, evaluate how Berkeley DB can satisfy your performance and concurrency requirements using a prototype model of software development.

Deployment (file-based database), and replication were life savers for my assignment.

The firm needed a database that could hold sizable volume, along with fast performance. We had many relational database options, but because the communication format of data was mostly FIXML, we really wanted to avoid changing the data shape. That is where dumping the XML directly, querying into business attribute using Xquery and creating custom database runtime helped us win big.

There have already been a lot of improvements since I last used the technology. However, I would be excited to see how the technology has developed into the area of blockchain.

Also, technical support is something they should improve.

I used for almost four years, from 2006-2010.

There were some mid-term small releases that caused database crashes, but this was later fixed.

I used technical support a few times, and found it responsive but turnaround time can be improved (6/10).

Oracle 10g XML was the closest to this product. However, open source along with opportunity to explore and add gave us the reasons to go ahead with this technology.

Initial setup was quite easy.

An in-house team implemented it. My advice is that you need to really learn this technology to use it better.

We always had predictability, and by using a custom-built data service layer with plugins, it provided us a lot of scalability, fast turnaround for our fast-moving business requirement and huge data.

We were quite satisfied with the product. For 2006-era technology, Berkley DB XML was quite unique and state-of-the-art.

It is a relatively easy to use key-value store. As a NoSQL solution, it has been around for quite a while, and thus been thoroughly tried and tested. It provides ACID transactions, which is not very common in the NoSQL universe. Response times are relatively fast. It runs as an embedded DB within your application, so a server is not necessary.

We have experienced two limitations:

- Oracle BDB Java edition does not support bulk retrieval of entries via their keys. In situations where various entries need to be retrieved, individual calls by key need to be made, instead of just firing one request with all of the keys. There is the alternative of using a cursor, but the whole key set would need to be traversed.

- Memory usage becomes a problem when the number of entries stored within the key/value store are quite high (hundreds of millions).

5 years

We encountered issues with the amount of memory necessary to keep the keys of the key value store in memory. Running BDB as an embedded database means we need to closely manage the amount of memory used by the application. The more our database grew, the higher the amount of memory used up by BDB. This soon became an issue when half of the 16GB on our web service was used up to store the keys of the key value store. We resolved the issue by adopting Voldemort, which uses BDB under the hood.

We did evaluate other key-value stores, and opted to use BDB because of its stability and support.

Setting up BDB as an embedded database is not complicated. It does, however, require close attention be paid to the reference documentation to tweak the database to work optimally.

Our implementation of BDB was done in-house. Pay attention whilst setting up the transaction levels, and tweak the database settings to improve read/write performance.

As a key/value store, Oracle BDB is simple to use, and it provides ACID transactions for companies that cannot afford eventual consistency. Oracle provides good documentation on the database, and when all else fails there is a community ready to help.