| Type | Title | Date | |
|---|---|---|---|
| Category | Data Warehouse | Apr 27, 2025 | Download |
| Product | Reviews, tips, and advice from real users | Apr 27, 2025 | Download |
| Comparison | IBM Db2 Warehouse vs Snowflake | Apr 27, 2025 | Download |
| Comparison | IBM Db2 Warehouse vs Oracle Exadata | Apr 27, 2025 | Download |
| Comparison | IBM Db2 Warehouse vs Teradata | Apr 27, 2025 | Download |
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| Teradata | 4.1 | 16.3% | 87% | 76 interviewsAdd to research |
| Snowflake | 4.2 | 15.2% | 97% | 100 interviewsAdd to research |
IBM Db2 Warehouse was previously known as InfoSphere Warehouse, IBM InfoSphere Warehouse.
We called our primary use case for this solution a data warehouse. It was data tapped from many, many different applications and mostly put into star schemas for historical reporting.
I think it scales really well and as long as you take enough time to learn a little bit about it, it works really well. If you have good people designing how the data is stored, it's a marvelous tool. If you have really, really bad designs, well, the tool might still be good, but it doesn't perform as well. But that's going to be true for anything.
The biggest problems we have is when the backup solution is failing or slow and we run out of log space, which has happened probably a couple of times in the last four years. It's traced back to something that changed on Tivoli Storage Management.
We started using this solution probably around 20 years ago, but we're migrating away from that now to SAP HANA and Azure.
The stability is pretty good.
This product is scalable.
Well, I think my partner and I would say different things. I found them to be pretty responsive. I did have a couple of occasions to open things and it troubled me how long it took to get action on those. Sometimes if I opened it in the morning, it might be fine. But if I opened it in the afternoon, it might be quite a long time, certainly next day, sometimes late the next day. But that's the service agreement we pay for, so that's what we get. I just wish it was faster.
Most of the time, I think they're great. Once in a while, they don't do as well as we'd like.
Most of our initial setups were straightforward. One of our data warehouse analytics platforms, which is our first implementation amongst all of our data, is now 16 partitions on four servers. And we have one large customer-facing application, that is 16 partitions on four servers. But everything else is around four partitions I'd say. But other than that, they're all pretty straightforward. We have a few, but they are in query in a production ward group cluster where I used them for Db2 with 40 or 50 databases in it. But each database is pretty straightforward.
For any database project, I really like to see good thought going into design upfront and use the standards so that people know what things mean about having to rediscover it when you go from one application to the next. So I believe in at least a place to share the vocabulary, if not a controlled vocabulary defining things, which is pretty old-fashioned I'm afraid. I also believes that companies need to pick a direction and stick with it and support it. And if they're going to go with this solution for a couple of years or if you had to have several solutions happening in parallel, you need to have really good criteria about when you go from one to one or when you go to another because sometimes it's challenging. It doesn't help the business if we're not being consistent.
